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1. 


INTRODUCTION 


Future  airborne  command,  control,  communications,  computing,  and  intelligence  (C^l) 
platforms,  such  as  the  advanced  Airborne  Warning  and  Control  Systems  (AWACS),  may 
be  required  to  support  multiple  high-resolution  on-board  sensors,  equally  high  data  rates 
from  off-board  sensors,  an  increased  crew  size  with  more  complex  consoles,  and  a 
sophisticated  battle  support  analysis  and  highly  interactive  battle  staff  decision  process. 
Therefore,  future  C'*!  aircraft  mission  avionics  suites  will  be  required  to  handle  a  much 
greater  aggregate  data  rate  than  is  the  case  today,  and  also  be  required  to  provide  a  much 
more  comprehensive  set  of  network  services  to  support  on-board  battle  staffs.  Current  on¬ 
board  networking  technology  cannot  meet  these  emerging  requirements. 

Asynchronous  Transfer  Mode  (ATM)  networking  technology  has  been  identified  as  a 
significant  potential  backbone  network  for  future  mission  avionics.  ATM  technology  has 
been  suceessfully  demonstrated  for  some  military  applications,  such  as  for  fixed  ground- 
based  fiber  networks,  and  the  extension  of  this  technology  into  the  RF  medium  is 
currently  under  way  with  field  demonstrations  expected  to  take  place  very  soon.  For 
potential  applications  to  airborne  C'*!,  an  ATM  local-area  network  had  been  successfully 
demonstrated  on  Casey  01,  but  the  demonstration  did  not  include  an  operational  scenario 
nor  was  it  configured  with  a  realistic  C''l  aircraft  avionics  suite.  Thus,  while  ATM 
undoubtedly  shows  significant  potential  to  meet  on-board  CT  network  requirements, 
ATM  network  applicability  and  cost  effectiveness  for  realistic  CT  aircraft  applications 
has  to  be  fully  implemented,  quantitatively  assessed,  and  operationally  demonstrated. 


2. 


PROGRAM  OBJECTIVE 


The  objective  of  this  program  was  to  design,  implement,  assess,  and  demonstrate  an 
ATM  network  in  a  realistic  airborne  demonstration  system  (i.e..  Advanced  AWACS 
prototype).  This  program  supports  realistic  O'*!  applications  such  as  battlespace 
management,  Synthetic  Aperture  Radar  (SAR)  signal  processing  and  analysis,  real-time 
Air  Tasking  Order  (ATO)  monitoring  concepts.  The  demonstration  system  includes  a 
suite  of  advanced  C^I  applications  and  will  be  an  integral  component  of  an  overall 
battlespace  simulation  activity.  We  accomplished  the  following  basic  goals:  (1) 
implemented  an  ATM  network  for  advanced  AWACS  systems,  (2)  developed  a 
quantitative  performance  measure  of  ATM  network  technology,  (3)  demonstrated  the 
integrated  battlespace  simulation  over  ATM  network  using  a  realistic  airborne  C"*! 
scenario,  and  (4)  performed  a  wireless  ATM  trade  study  that  includes  the  AWACS  on¬ 
board  and  off-board  network  trade  study.  This  program  represents  a  significant  step 
forward  in  the  development  of  on-board  network  technology  for  future  C"*!  and  similar 
aircraft,  and  in  particular  for  the  mission  avionics  suite  of  an  advanced  AWACS. 
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3. 


PROGRAM  SUMMARY 


The  thrust  of  this  program  was  to  configure  the  existing  prototype  AWACS  Open  System 
Architecture  (OSA)  mission  avionics  system  with  an  ATM  network  and  demonstrate  the 
integrated  battlespace  simulation  using  ATM-based  AWACS  prototype  system  for 
realistic  C''!  applications.  The  advanced  AWACS  prototype  is  currently  implemented 
with  Ethernet  and  Fiber  Distributed  Data  Interface  (FDDI)  networks.  Key  program 
milestones  were  an  interim  demonstration  of  the  Advanced  AWACS  subsystem  with 
ATM  backbone  networks  and  the  final  demonstration  of  integrated  battlespace  simulation 
including  all  three  elements  of  the  “sensor-  C''l-fighter”  loop.  The  Advanced  AWACS 
ATM  network  demonstration  program  flow  is  shown  in  Figure  3-1. 
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Figure  3-1;  Demonstration  Process  of  ATM-Based  Advanced  AWACS  Network 


Task  1:  ATM-Based  Architecture  Definition 

The  current  advanced  AWACS  OSA  network  incorporates  legacy  LANs,  with  separate 
lOBase-T  Ethernet  and  FDDI  providing  backbone  connectivity  between  the  mission 
computer  and  display  consoles  and  for  external  connectivity.  These  two  separate 
networks  were  replaced  with  a  single  ATM  network.  The  ATM-based  network 
architecture  was  designed  consistently  with  the  OSA  concept  for  Advanced  AWACS. 


Task  2;  ATM-Based  Network  Implementation 

The  Commercial  Off-The-Shelf  (COTS)  software  and  hardware  (e.g.,  platforms, 
switches,  network  interface  cards),  based  on  the  design  study  of  Task  1 ,  were  evaluated, 
down-selected,  acquired,  and  implemented  into  the  Advanced  AWACS  prototype  system. 

Task  3:  Subsystem  Testing  and  Performance  Evaluation 

The  performance  evaluation  test  of  the  ATM-based  systems  was  performed  on  both 
network  and  application  levels.  A  set  of  application-specific  performance  criteria  were 
established. 

Task  4:  Interim  Laboratory  Demonstration 

The  Advanced  AWACS  functionality  was  demonstrated  over  the  ATM  network.  This 
interim  demonstration  relied  on  a  pre-programmed  AWACS  application  demonstration, 
including  target  simulations  (over  1,000  targets),  sensor  returns  from  the  simulated 
targets  (e.g..  Radar,  IFF,  ESM),  and  tracking  processing  (Figure  3-2). 

Task  5:  Integrated  Battlespace  Demonstration 

The  Advanced  AWACS,  UAV  ground  station,  and  advanced  fighter  are  integrated  onto 
ATM-based  networks  and  are  used  for  a  realistic  battlespace  scenario  demonstration. 


Interim  Demonstration 

Final  Demonstration 

Advanced  AWACS  Subsvstem 

•  over  1,000  simulated  targets 

•  over  1,000  system  tracks 

•  up  to  1 ,000  simulated  sensor  returns, 
e.g.,  radar,  IFF,  ESM 

Integrated  Battlespace  Simulation 

•  various  types  of  sensor  inputs,  e.g., 
SAR,  IR,  video 

•  breadboard  of  typical  Adv.  Fighter 

•  information  transfer  between  HITL 
systems  (DEMPC  and  Adv.  AWACS) 

Figure  3-2:  Interim  and  Final  Demonstration  Features 


Task  6:  Wireless  ATM  Study 

The  trade  study  of  the  on-board  networks  in  the  existing  AWACS  programs  was 
performed.  This  trade  study  includes  the  off-board  network;  the  survey  and  future  works 
on  wireless  ATM  technologies  —  wireless  satellite,  wireless  terrestrial,  and  wireless 
mobile  ATM. 
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4. 


ATM-BASED  ARCHITECTURE  DEFINITION  (TASK  1) 


Future  airborne  C"*!  platforms,  such  as  an  Advanced  AWACS,  will  increasingly  have  to 
provide  sophisticated  battle  staffs  with  advanced  command  and  control  decision  aids  and 
multiple  off-board/on-board  sensor  data  fusion  capability,  resulting  in  the  need  for  a  real¬ 
time,  higher  data  rate  mission  avionics  network.  This  network  must  support  multiple  data 
types  (data,  voice,  video,  image)  across  multiple  end-user  stations  on  the  aircraft,  and 
eventually  seamless  communication  capability  between  end-user  stations  on-board  and 
off-board  the  aircraft. 

4.1.  ATM  Technology  for  AWACS  Platforms 

Functional  requirements  of  these  C'*I  aircraft  will  include  interactive  fighter  control 
(voice),  sensor  data  processing  (including  imagery)  for  targeting  and  situation 
assessment,  real-time  control  of  guided  weapons,  and  Remotely  Piloted  Vehicles  (RPV) 
with  sensor  payloads.  Data  rate  requirements  internal  to  the  C''l  aircraft  are  expected  to 
progress  rapidly  from  1  Mbps  currently  for  the  E-3,  through  approximately  5  to  10  Mbps 
for  retrofits  to  current  platforms  (e.g.,  E-6),  to  500  to  600  Mbps  for  future  C'*!  systems. 

In  an  ATM  network,  the  information  is  transported  by  means  of  streams  of  short  fixed- 
length  packets  (cells)  that  are  asynchronous  time-division  multiplexed.  ATM  is  expected 
to  be  capable  of  effectively  emulating  any  service  and  thus  provide  high-throughput,  low- 
delay,  service  independent  transport  for  all  types  of  traffic.  The  advantages  of  ATM  are: 

•  Flexibility  to  support  existing  services  and  unforeseen  future  services. 

•  Dynamic  bandwidth  allocation. 

•  Integrated  transport  of  all  types  of  mixed  media  information. 

•  Efficient  use  of  network  resources  by  statistical  multiplexing. 

Therefore,  the  architecture  for  future  C*!  aircraft  networks  will  take  advantage  of  ATM 
technology  to  provide  the  network  with  the  capacity  for  a  wide  variety  of  applications 
ranging  from  highly  interactive  to  minimally  interactive  systems. 

4.2.  AWACS  Open  System  Architecture  Network  Requirements 

The  AWACS  Open  System  Architecture  (OSA)  requirements  are  as  follows: 

(a)  Support  periodic  database  distribution,  on-demand  messages,  file  sharing,  video,  and 
voice. 

(b)  Support  very  high  multicast  data  load  (>  40  Mbps)  to  each  node  for  database 
distribution  (up  to  32  nodes). 

(c)  Support  node  scalability  to  48  nodes. 

(d)  Support  full  capability  of  TCP  and  UDP  (for  multicast)  on  the  network,  although  it 
does  not  have  to  be  locked  into  using  IP  for  database  distribution. 

(e)  The  buffer  overflow  should  be  avoided  at  end  nodes.  The  end  nodes  which  receive 
multicasts  will  be  very  susceptible  to  buffer  overflow  conditions  and  the  host 
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processors  cannot  be  dependent  on  the  Network  Interface  Cards  (NICs)  buffer 
capacity  at  a  line  rate.  Therefore,  a  flow  control  mechanism  is  required. 

(f)  No  single-point  failure  modes. 

(g)  Each  node  needs  to  attach  to  two  networks  (dual  homing). 

(h)  Database  distribution  does  not  necessarily  need  to  be  on  top  of  an  internetworking  or 
routing  protocol.  No  routing  can  take  place  for  any  data  on  the  network.  The  set  of 
data  configurations  on  the  network  will  not  change  frequently. 

4.3.  Demonstration  Systems  Architecture  Definition 

Analysis  of  tactical  or  reconnaissance  Hardware-In-The-Loop  (HITL)  and  C^I 
applications  using  Advanced  AWACS  as  the  centralized  airborne  information  platform 
leads  to  the  conclusion  that  the  corresponding  system  architecture  is  a  critical  aspect  of 
the  system's  ultimate  effectiveness  in  that  role.  The  choice  of  communications 
architecture  is  constrained  by  the  required  fiinctional  architecture  of  the  system,  such  as 
legacy  interfaces,  monitor  and  control  stations. 

Our  rationale  for  migrating  to  ATM  is  based  on  expected  benefits  in  network  attributes 
from  both  theoretical  and  practical  perspectives.  Although  some  of  the  features  of  ATM 
are  not  currently  available  off  the  shelf,  or  currently  require  integration  and  rework  to  be 
operable,  we  are  convinced  that  the  long-term  benefits  will  outweigh  the  short-term 
difficulties,  hence  the  importance  of  this  work. 

The  appropriateness  of  ATM  versus  a  switched-LAN  implementation  is  based  on  two 
important  practical  considerations.  The  first  consideration  centers  on  the  ability  to 
seamlessly  support  all  forms  of  potential  applications,  i.e.,  multi-media,  simultaneously 
and  completely.  In  this  regard,  only  ATM  combines  the  advantages  of  statistical 
multiplexing  with  the  use  of  small  connection-oriented  data  cells  to  achieve  practical 
jitter  performance  and  optimal  link  utilization.  Also,  while  most  existing  Application 
Programmable  Interfaces  (APIs)  are  compatible  with  any  LAN  technology,  only  ATM 
allows  for  eventual  migration  to  native  ATM  APIs  whereby  many  of  the  subtle 
advantages  of  ATM  will  be  realized. 

The  second  consideration  centers  on  the  relative  ease  with  which  network  data  can  be 
converted  and  carried  on  different  media  such  as  LANs  and  telecommunications  lines, 
optical  fiber,  and  air.  To  date,  ATM  is  by  far  the  strongest  long-term  candidate  for  use  as 
a  communications  substrate  technology  between  these  differing  communication  forms. 
Examples  are  LAN  Emulation  (LANE),  ATM  on  Tl,  ATM  on  OC-3c,  and  link 
accelerators  and  modems  necessary  to  implement  an  ATM  RF  air  interface.  Given  the 
strong  push  for  current  and  future  remote  operability  and  equipment  interoperability, 
ATM  appears  to  be  the  best  long-term  choice. 

We  defined  three  system  architectures:  the  existing  system  configuration  (Figure  4.3-1), 
the  interim  system  configuration  (Figure  4.3-2),  and  the  final  system  configuration 
(Figure  4.3-2). 
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Existing  Architecture:  The  existing  system  configuration  of  an  integrated  battlespace 
simulation  (Figure  4.3.1)  employs  separate  Ethernet  and  FDDl  networks  to  implement 
message  bursts  and  file  transfers,  respectively.  The  Ethernet  connects  the  mission 
computer  to  the  display  consoles  via  the  lOBase-2,  tapped  coaxial  cable  configuration. 
An  additional  Ethernet  is  used  to  provide  connectivity  to  the  Distributed  Interactive 
Simulation  (DIS)  network.  The  FDDI  connects  not  only  the  same  workstations  as  the 
Ethernet,  but  also  connects  the  Data  Exploitation,  Mission  Planning,  and 
Communications  (DEMPC)  mission  planner  and  DEMPC  image  analyzer,  providing  the 
high-speed  communications  core  of  the  system.  The  FDDl  network  employs  an 
additional  concentrator  unit  that  serves  to  convert  the  physical  topology  of  the  network 
from  a  ring  to  a  star. 
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Figure  4.3-1:  Existing  Integrated  Battlespace  Simulation  Demonstration  System 


Interim  Demonstration  Architecture:  The  interim  system  configuration  (Figure  4.3-2) 
combines  the  data  traffic  present  on  the  separate  Ethernet  and  FDDl  networks  onto  an 
ATM  backbone.  ATM  LAN  Emulation  (LANE)  technology  will  be  used  against  separate 
Permanent  Virtual  Circuits  (PVC)  to  establish  coimectivity  similar  to  that  in  the  existing 
system  configuration.  ATM  LANE  can  support  all  existing  IP  applications,  so  TCP/IP 
and  UDP/IP  can  run  over  LANE.  The  PVCs  will  also  be  able  to  support  OSA  database 
multicasts  while  a  separate  “Classical  IP  over  ATM”  (RFC  1577)  will  run  simultaneously 
over  Switched  Virtual  Circuits  (SVC)  supporting  all  existing  IP  applications.  As  such, 
the  ATM  backbone  will  provide  connectivity  between  the  OSA  mission  computers,  the 
OSA  display  consoles,  the  DEMPC  mission  planner,  and  the  DEMPC  image  analyzer, 
providing  all  inter-workstation  communications  for  the  system.  The  ATM  backbone 
employs  an  ATM  switch  in  the  final  system  configuration. 
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Final  Demonstration  Architecture:  The  final  system  configuration  (Figure  4.3-2)  connects 
the  UAV  subsystem  and  advanced  fighter  subsystem  to  the  Advanced  AWACS 
subsystem.  The  UAV  subsystem  consists  of  the  UAV  sensor  and  ground  station.  The 
advanced  fighter  subsystem  comprises  the  cockpit  display  and  the  display  generator.  For 
the  actual  demonstration,  a  simulated  real-time  Synthetic  Aperture  Radar  (SAR)  image 
will  be  used.  The  SAR  image  will  be  taken  from  the  image  generator’s  visual  database. 
The  video  data  will  be  captured  and  processed  by  the  SGI  Indigo2  sensor  (SAR)  video 
processor  and  transmitted  via  an  RS-170  video  link  to  the  image  analysis  display  on  the 
DEMPC  ground  station.  Additional  information  will  be  added  to  the  image  which  will 
then  be  transmitted  via  ATM  to  the  OS  A  DEC  Alpha  AWACS  operator’s  station.  The 
resultant  image  will  then  be  passed  to  the  SGI  Onyx  cockpit  display  processor  via  an 
ATM  link  along  with  voice  communications  between  the  shooter  and  the  CT  platform. 
The  information  that  is  displayed  in  the  shooter’s  cockpit  will  be  used  as  targeting 
information. 


Figure  4.3-2:  Interim  and  Final  Demonstration  System 
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4.4.  ATM  Multicast  Solutions  for  AW  ACS  Applications 

The  CT  platform  (e.g.,  AW  ACS)  requires  a  network  that  is  capable  of  simultaneous 
unicast  and  multicast  for  data  distribution.  The  TCP/IP  unicast  is  used  for  operator- 
related  activities  between  the  AWACS  mission  computer  and  display  consoles.  The 
UDP/IP  multicast  is  used  for  common  data  broadcasting  to  all  display  consoles  within  a 
multicast  group  on  a  periodic  basis.  Unlike  a  connectionless  legacy  LAN  technology,  the 
multicast  capability  is  not  easy  to  implement  with  connection-oriented  ATM  technology. 
The  ATM  multicast  configuration  used  for  the  integrated  battlespace  simulation  network 
is  described  in  the  following  sections. 

4.4.1.  ATM  Multicast  Technology 

There  are  potential  approaches  to  address  the  ATM  multicast  problem  in  the  legacy  LAN 
environment;  for  example,  multipoint-to-multipoint  Virtual  Path  Connections  (VPC),  a 
multicast  server,  or  overlaid  point-to-multipoint  connections.  However,  the  multipoint-to- 
multipoint  VPC  requires  a  protocol  to  allocate  unique  VCI  values  to  all  nodes  in  the 
multicast  group;  such  a  mechanism  does  not  currently  exist.  The  multicast  server 
requires  a  point-to-multipoint  connection  with  all  nodes,  as  well  as  a  point-to-point 
unidirectional  connection  from  each  node  to  a  multicast  server.  The  overlaid  point-to- 
multipoint  connections  requires  each  node  to  maintain  the  total  number  of  all  connections 
within  each  group.  Thus,  there  is  no  ideal  solution  yet  for  ATM  multicast.  The  existing 
“Classical  IP  over  ATM  (CIP)”  protocol  supports  neither  broadcast  nor  multicast,  while 
the  ATM  LAN  Emulation  (LANE)  protocol  supports  only  a  broadcast.  The  higher  layer 
protocols  for  ATM  IP  multicasting  (e.g.,  MARS,  MPOA,  PIM)  are  under  development. 

4.4.2.  ATM  Classical  IP-Based  Multicast  Solution 

The  ATM  classical  IP  (CIP)  protocol  lacks  a  broadcast  (multicast)  mechanism.  We 
resolved  this  broadcast  (multicast)  problem  of  ATM  classical  IP  with  a  simple 
configuration  solution.  The  simple  solution  is  to  set  up  point-to-multipoint  Permanent 
Virtual  Circuit  (PVC)  connections  (Multicast  PVC)  from  a  broadcast  server  to  all  clients. 
Since  there  is  no  such  server  in  CIP,  we  create  a  virtual  broadcasting  node  (that 
corresponds  to  a  broadcast  service  access  point)  at  the  switch.  The  procedure  to 
configure  this  CIP  broadcast  (multicast)  mechanism  is  as  follows. 

(a)  Configure  an  ATM  interface  (qaaO)  for  a  standard  “Classical  IP  over  ATM”  with  an 
appropriate  ATMARP  server  address,  operating  over  Switched  Virtual  Circuit  (SVC) 
connections. 

(b)  Create  at  an  ATM  switch  a  point-to-multipoint  Permanent  Virtual  Circuits  (PVC) 
node  (Multicast  PVC)  using  unique  vpi/vci  numbers  for  each  multicast  group,  e.g., 
AWACS,  Fighter,  and  UAV  multicast  group  subnets.  This  Multicast_PVC  virtual 
node  serves  as  a  broadcasting  access  point. 
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(c)  Create  a  virtual  IP  address  for  the  Multicast  PVC  virtual  node.  Note  that  a  unique  IP 
subnet  address  should  be  assigned  to  each  multicast  group  when  multiple  subnets  are 
required. 

(d)  Configure  a  new  ATM  interface  (qaal)  for  a  CIP  Multicast  PVC  virtual  node  at  both 
the  host  and  the  client  workstations  with  a  proper  virtual  IP  address.  Repeat  the 
process  for  the  multiple  subnets,  as  required. 

•  ifconfig  qaal  <host  station  multicast  IP  address>  netmask  255.255.255.0  at  a  host 
station. 

•  ifconfig  qaal  <client  stations  multicast_PVC  virtual  IP  address>  netmask 
255.255.255.0  at  all  client  stations. 

(e)  Bind  IP  addresses  to  the  unique  vpi/vci  numbers  at  a  host  workstation  and  multiple 
client  workstations,  such  as 

•  atmarp  -c  <client  stations  multicast_PVC  virtual  IP  address>  qaal  <vpi>  <vci> 
<revalidate>  at  a  host  station. 

•  atmarp  -c  <host  station  multicast  IP  address>  qaal  <vpi>  <vci>  <revalidate>  at 
all  client  stations. 

(f)  Make  the  final  configuration  (e.g.,  atmarp)  persistent  across  reboots  by  a  start  up 
script  as  necessary. 

Run  a  standard  “Classical  IP  over  ATM“  on  top  of  “Multi cast_PVC”.  This  permits 
the  simultaneous  transmission  of  point-to-point  TCP  unicast  traffic  over  SVC,  and 
point-to-multipoint  UDP  multicast  traffic  over  multicast  PVC. 

4.4.3.  ATM  LAN  Emulation-Based  Multicast  Solution 

ATM  LANE  can  support  multiple  independent  emulated  LANs  (ELAN),  and  the 
membership  in  any  of  the  ELANs  is  independent  of  the  physical  location  of  the  end 
system.  For  the  integrated  battlespace  simulation,  four  different  ELANs  were  set  up  to 
support  the  ATM  multicast  groups:  ELAN-1  (AW ACS  display  consoles  subnet),  ELAN- 
2  (fighter  subnet),  ELAN-3  (UAV  subnet),  and  ELAN-4  (voice  over  ATM  subnet).  The 
AWACS  mission  computer  must  be  a  member  of  all  ELANs  so  that  it  can  selectively 
broadcast  information  to  any  of  the  AWACS,  fighter,  or  UAV  groups  as  different 
multicast  groups.  It  should  be  noted  that  the  CIP  (or  LANE)  intrasubnet  protocol  works 
only  within  its  own  logical  IP  subnet  (or  ELAN),  thus  a  separate  router  is  required  for 
communications  between  different  logical  subnets  (or  ELANs). 
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Initialization  and  Configuration: 

(a)  LAN  Emulation  Client  (LEC)  registers  its  own  ATM  address. 

•  Upon  initialization  (power  up),  LEC  obtains  its  own  ATM  address  typically 
through  address  registration. 

(b)  LEC  requests  to  join  ELAN. 

•  LEC  first  finds  the  LAN  Emulation  Configuration  Server  (LECS)  address  by 
either  the  locally  configured  ATM  address  (bypassing  LECS),  Interim  Local 
Management  Interface  (ILMI),  well-known  LECS  address,  or  PVC  (VPI=0, 
VCI=17). 

•  LEC  sets  up  a  bidirectional  point-to-point  connection  (Configure  Direct  VCC)  to 
LECS  and  sends  LE_CONFIGURE_REQUEST  to  find  LES  ATM  address. 

(c)  LECS  identifies  LAN  Emulation  Server  (LES)  and  provides  LES  identification  to 

LEC. 

•  LECS  returns  LE_CONFIGURE_RESPONSE  to  LEC  with  LES  ATM  address, 
ELAN  type,  ELAN  name,  and  ELAN  maximum  packet  size. 

Joining  and  Registering  with  LES: 

(d)  LEC  registers  with  LES 

•  LEC  clears  the  configuration-direct  connection  to  LECS  and  sets  up  a 
bidirectional  point-to-point  connection  (Control  Direct  VCC)  to  LES  for  exchange 
of  the  control  traffic  and  then  sends  LE_JOIN_REQUEST. 

•  When  Control  Direct  VCC  is  established  between  LEC  and  LES,  it  remains  so 
that  no  two  LECs  register  the  same  Medium  Access  Control  (MAC)  or  ATM 
address. 

(e)  LES  verifies  with  LECS  that  LEC  is  allowed  to  join  the  ELAN 

•  Upon  receipt  of  LE_JOIN_REQUEST,  the  LES  sets  up  bidirectional  point-to- 
point  connection  (Server  Configure  Direct  VCC)  to  LECS  for  verifying  that  LEC 
is  allowed  to  join  the  ELAN. 

•  LES  configuration  request  (Server  Configure  Direct  VCC)  contains  LEC  MAC 
address,  LEC  ATM  address,  and  ELAN  name. 

•  LECS  checks  its  database  to  determine  whether  the  LEC  can  join  the  ELAN;  then 
it  uses  the  same  VCC  to  inform  the  LES  whether  the  LEC  is  allowed  to  join. 

(f)  LES  allows  or  does  not  allow  the  LEC  to  join  the  ELAN. 

•  Upon  verification  of  LEC’ s  membership,  LES  adds  the  LEC  as  a  leaf  and  sets  up 
the  unidirectional  point-to-multipoint  connection  (Control  Distribute  VCC). 

•  LES  confirms  the  registration  over  bidirectional  point-to-point  connection 
(Control  Direct  VCC)  by  sending  LE_JOIN_RESPONSE  to  the  LEC.  LEC  has 
successfully  joined  the  LES.  On  the  other  hand,  if  not  allowed,  LES  rejects  the 
registration  over  bidirectional  point-to-point  connection  (Control  Direct  VCC). 


11 


Finding  and  Joining  the  Broadcast  and  Unknown  Server  (BUS): 

(g)  LEC  sends  LE-ARP  packets  to  LES  for  finding  the  BUS  ATM  address. 

•  LEC  creates  a  LE_ARP_REQUEST  packet  with  MAC  address  (OxFFFFFFFF) 
and  sends  it  to  LES  over  the  control-direct  VCC  to  find  a  MAC  broadcast  address. 

•  LES  responds  to  LEC  with  the  BUS  ATM  address  on  the  control-distribute  VCC. 

(h)  LEC  sets  up  the  multicast-send  connection  to  BUS. 

•  LEC  creates  a  signaling  packet  with  BUS  ATM  address  and  sets  up  a  bidirectional 
point-to-point  connection  (Multicast  Send  VCC)  to  BUS. 

(i)  BUS  sets  up  the  multicast-forward  connection  to  LEC. 

•  Upon  receipt  of  a  signaling  packet,  BUS  adds  the  LEC  as  a  leaf  and  sets  up  an 
unidirectional  point-to-multipoint  connection  (Multicast  Forward  VCC)  to  LEC. 
(Note  that  the  BUS  is  allowed  to  set  up  the  unidirectional  point-to-point  VCCs  to 
LECs,  but  the  use  of  point-to-multipoint  VCCs  relieves  the  BUS  from  duplicating 
and  transmitting  many  copies  of  each  message). 

•  LEC  is  now  a  member  of  the  ELAN  and  is  ready  for  data  transfer. 

Data  Transfer: 

(j)  BUS  floods  a  data  packet  to  all  LECs  on  the  ELAN. 

•  When  LEC  has  a  data  packet  to  send  to  an  unknown  destination  MAC  address, 
LEC  sends  the  data  frame  to  BUS  over  the  multicast-send  VCC  and  the  BUS 
distributes  it  to  all  LECs  on  the  ELAN  over  the  multicast-forward  VCC. 

•  This  is  done  because  the  ATM  address  resolution  may  take  some  time  and  many 
network  protocols  are  intolerant  of  delays. 

(k)  LEC  resolves  an  ATM  address  of  the  unknown  destination  LEC. 

•  LEC  sends  a  LE_ARP_REQUEST  control  frame  to  LES  over  the  control-direct 
VCC.  If  LES  knows  the  ainswer,  it  will  respond  with  the  ATM  address 
corresponding  to  the  Medium  Access  Control  (MAC)  address  of  the  LEC. 

•  If  LES  does  not  know  the  answer,  it  floods  the  LE_ARP_REQUEST  to  some  or 
all  LECs  over  the  control-distribute  VCC. 

(l)  LEC  sends  BUS  LANE  flushing  message  and  then  starts  data  transfer 

•  Upon  receipt  of  LE  ARP  RESPONSE,  LEC  sets  up  a  bidirectional  point-to-point 
connection  (Data  Direct  VCC)  to  the  destination  LEC  and  uses  this  for  data 
transfer  rather  than  the  BUS  path. 

•  When  LEC  establishes  the  data-direct  VCC,  it  sends  a  control  broadcast  message 
(i.e.,  FLUSH  MESSAGE)  following  the  last  packet  to  BUS  and  waits  for  the 
destination  to  acknowledge  receipt  of  the  flush  packet.  The  LANE  Flush 
procedure  ensures  that  all  packets  previously  sent  to  the  BUS  were  delivered 
(flushed)  to  the  destination  prior  to  the  use  of  the  data-direct  VCC. 

•  The  LEC  then  starts  to  send  data  across  the  data-direct  VCC  without  the  risk  of 
frames  interleaving. 
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5. 


ATM  NETWORK  IMPLEMENTATION  (TASK  2) 


The  primary  objective  of  this  task  was  to  integrate  all  components  of  the  Advanced 
AWACS  subsystem  into  the  final  demonstration  configuration.  In  this  task,  first  we 
performed  a  vendor  trade  study  on  the  necessary  COTS  hardware  and  software,  second 
we  acquired  all  required  system  components,  and  finally  we  integrated  all  components  of 
the  Advanced  AWACS  subsystem  into  the  interim  demonstration  configuration. 

5.1.  ATM  Switch  and  Analyzer  Selection 

The  trade  study  on  the  selection  of  COTS  hardware  (e.g.,  ATM  switch),  software,  and 
related  test  equipment  was  performed.  After  an  initial  screening,  three  vendors’  products 
were  selected  as  candidates. 

ATM  Switch  Requirements:  The  ATM  switch  had  to  address  the  full  range  of 
requirements  including: 

•  Broadcast/multicast  capability. 

•  LANE  BUS  throughput  (>  40  Mbps)  to  each  node  (up  to  32  nodes). 

•  Support  full  TCP/IP  and  UDP/IP  capability  on  the  network. 

•  No  buffer  overflow  at  end  nodes. 

Evaluation:  A  list  of  our  requirements  was  provided  to  the  vendors.  Based  on  these 
requirements,  a  series  of  technical  evaluations  and  tests  on  the  preselected  vendors’  ATM 
switches  were  performed  during  this  reporting  period.  The  major  issues  were  the 
multicast  capability  and  LAN  Emulation  (LANE)  Broadcast  and  Unknown  Server  (BUS) 
throughput,  which  are  the  important  metrics  for  real-time  C"*!  systems.  The  ATM  LANE 
BUS  is  responsible  for  forwarding  all  broadcast  (or  multicast)  and  unknown  destination 
unicast  frames  (received  from  members  of  the  ELAN)  to  all  members  of  the  ELAN.  The 
LANE  BUS  throughput  test  measures  the  ability  of  a  BUS  to  forward  frames.  Since  the 
AAL5  Protocol  Data  Units  (PDU)  do  not  allow  the  interleaving  of  cells  of  different 
frames  during  the  forwarding  procedure,  the  BUS  should  serialize  the  received  frames 
prior  to  forwarding  them.  As  a  result,  the  performance  of  the  Segmentation  And 
Reassembly  (SAR)  on  the  BUS  is  the  most  significant  factor  affecting  overall  BUS 
performance.  Given  the  fact  that  some  BUS  implementations  perform  the  SAR  in 
software,  while  others  provide  it  in  hardware,  the  BUS  performance  varies  substantially. 
The  following  Figure  5.1-1  summarizes  the  evaluation  and  test  results  on  the  major 
vendors’  ATM  switches. 

Conclusion:  Based  on  the  trade  study  and  a  series  of  evaluation  and  testing  efforts,  we 
selected  the  Cisco  Systems  LS-lOlO  ATM  switch  (with  Catalyst  5000  LANE  module) 
and  the  3Com  Cellplex  7000  ATM  switch. 
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Requirements  or 
Capabilities 

CISCO 

LSlOlO 

with  Catalyst  5000 

FORE 

ASX-200BX 

3COM 

CellPlex  7000 

1.  Switch  call  setup  rate 
(450  calls) 

195  calls  completed 
per  second 

130  calls  completed  per 
second 

1 1  calls  completed  per 
second 

(limit  to  325  calls) 

2.  Switch  call  setup 
latency  (450  calls) 

<  0. 1  sec 

>  2.0  sec 

“ 

3.  ATM  LANE 

Yes 

Yes 

Yes 

4.  BUS/LES  location 

Outside  switch, 
in  a  different  box 
(Catalyst  5000) 

Inside  switch, 
in  the  same  box 

Outside  switch 
in  the  same  box 

5.  SAR  implement  on 
the  BUS 

SAR  in  hardware 

SAR  in  software 
(This  limits  BUS 
performance) 

SAR  in  hardware 

6.  LANE  multicast 
capability 

Yes 

Yes 

Yes 

7.  Throughput 
(50  Mbps  to  32  clients) 

Yes 

No 

Yes 

8.  BUS  broadcasting 
speed 

14,881  frames/sec 
over  1  ELAN  1 19,000 
ffames/sec 
over  6  ELANs 

1,488  frames/sec 
over  1  ELAN 

14,881  frames/sec  over 

1  ELAN 

89,000  frames/sec 
over  6  ELANs 

9.  BUS  throughput 

4,880  frames/sec 
for  24-frame  burst 
5,480  frames/sec 
for  744-fTame  burst 

2,060  frames/sec 
for  24-frame  burst 
2,060  frames/sec 
for  744-frame  burst 

4,880  frames/sec 
for  24-frame  burst 
7,440  frames/sec 
for  744-frame  burst 

10.  Frame  handling 
(%  successful  deliver) 

100  %,  94  % 
for  24-,  744-frame 
bursts 

32  %,  27  % 
for  24-,  744-frame 
bursts 

100%,  100% 
for  24-,  744-frame 
bursts 

Figure  5.1-1:  Performance  Comparison  of  Multiple  Vendors’  ATM  Switches 


ATM  Network  Analyzer  Requirements:  The  ATM  network  analyzer  should  be  able  to 

address  the  range  of  requirements,  including: 

•  The  ATM  analyzer  should  be  able  to  address  all  our  requirements  to  satisfy  the  ATM 
network  performance  evaluation  task  during  the  program. 

•  The  second  ATM  analyzer  was  required  to  be  portable  because  of  the  need  to  move 
among  three  laboratories  (Bldg,  7-81-7,  Bldg.  18-233,  or  ITDL  facility)  due  to  multi- 
organizational  involvement  in  this  Rome  Lab  program  for  an  ATM-based  AWACS 
network  demonstration. 

•  It  was  very  highly  desirable  for  the  second  ATM  Analyzer  to  be  compatible  and/or 
interchangeable  with  the  existing  HP  VXI-based  E4100B  ATM  Broadband  System. 

•  The  ATM  analyzer  had  to  have  an  easy  upgrade  path  to  future  higher  data  rates. 
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Evaluation:  The  list  of  test  standards  and  parameters  were  provided  in  advance  to  the 
vendors.  Based  on  the  given  test  standards  and  parameters,  a  series  of  evaluation  and 
testing  on  the  selected  major  vendors’  ATM  analyzers  were  performed  in  our  laboratory 
during  this  reporting  period.  Figure  5.1-2  summarizes  the  ATM  analyzer  evaluation  and 
test  results. 


Capability 

HP 

4100B 

HP 

5200A 

W&G 

DA-30C 

Note 

1.  Decoding  capability 
of  traffic  in  monitoring 
mode 

Yes 

Yes 

Yes 

At  various  protocol  layers  such  as 
ATM,  AAL,  LANE,  TCP,  UDP, 
Classical  IP 

2.  Capture  capability 
of  traffic 

Yes 

Yes 

Yes 

As  an  edge  device  over  UNI  under 
LANE,  Classical  IP,  AAL,  and 
ATM 

3.  Source  capability 
of  traffic 

Yes 

Yes 

except 

LANE 

No 

Yes  with  PVC 
except  LANE 

As  an  edge  device  over  UNI  under 
LANE,  Classical  IP,  AAL,  and 
ATM 

4.  Emulation  capability 

Yes 

Yes 

for  UNI, 
NNI 

No 

No  NNI 
(Some 
emulation 
available  in 
Version  2.0) 

Traffic  capture  and  analysis 

UNI  signaling  in  emulation 

NNI  signaling  in  emulation 

5.  Conformance  test 

Yes 

No 

No 

UNI,  NNI  signaling 

6.  Quality  of  Service 
(QoS)  test  capability 

Yes 

Yes 

No 

for  some  QoS 
parameters 
(Improve  in 
Version  2.0) 

Cell  delay  variation  (jitter) 

Maximum  cell  delay 

Mean  cell  delay 

Cell  loss,  cell  error  ratio 

Cell  misinsertion  ratio,  etc. 

Figure  5.1-2:  Performance  Comparison  of  Multiple  Vendors’  ATM  Analyzers 


Conclusion:  Based  on  the  trade  study  and  a  series  of  evaluation  and  testing  efforts,  we 
selected  a  Hewlett-Packard  E5200A  portable  broadband  service  analyzer  that  was 
superior  to  any  other  models.  Without  the  version  2.0,  the  capability  of  the  existing 
version  1.2  of  the  Wandel  &  Golterman  (W&G)  DA-30C  ATM  analyzer,  was  somewhat 
limited. 
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5.2.  AWACS-UAV-Fighter  Platforms  Selection 

There  were  three  different  applicable  platforms  or  environments:  Digital  Equipment 
Corporation  (DEC)  Alpha  600  processors  running  DEC  Unix  on  a  PCI  backplane,  SUN 
Sparc-20  workstations  running  Solaris  on  an  Sbus  backplane,  and  SGI  Onyx  workstations 
running  IRIX  on  a  VMEbus  backplane.  The  first  two  systems  were  required  for  the 
interim  demonstration  and  all  three  of  them  were  required  for  the  final  demonstration. 
The  core  battlespace  components  were  simulated  with  the  multiple,  high-end  platforms 
on  ATM  network  testbed  (Figure  5.2):  AW  ACS  for  DEC  Alpha-500/600  workstations 
running  Unix  4.0  on  PCIbus,  UAV  for  SUN  Sparc-20  running  Solaris  2.4  on  Sbus,  and 
Fighter  for  SGI  Onyx-1  (Onyx-2)  running  Irix  5.3  (Irix  6.4)  on  VMEbus  (PCIbus). 


LIS-l 

ELAN-1 


LIS-3 

ELAN-3 


LIS-3 

ELAN-3 


LIS-2 

ELAN-2 


LIS-4 

ELAN-4 


DEC  Alpha  500 
AWACS 
Big  FPD  Screen 
E:  DELTA 


OC-3 


100Base-T 

Ethernet 


SUN  Sparc  20 
UAV 

M  ission  Planner 
(Dem  pc  6.1) 


SUN  Sparc  20 
UAV 

Image  Analyzer 
(Dem pc  6.2) 


SG 1  Onyx  II 

VR-IOO 

Advanced  Fighier 

Audio  Radio 

display  Generator 

for 

(Osprey) 

Adv.  Fighter 

OC-3 


ATM  LAN  Switch 
Catalyst  5000 


pC-3 


OC-3 


OC-3 


ATM  Switch 
LS-IOlO 


bc-3 


Voice  over 
ATM 


OC-3 


ATM  LAN  Switch 
Cataivst  5000 


OC-3 


VR-lOO 

1 

DEC  Alpha  600 

Audio  Radio 

1 

AWACS 

for 

1 

Mission  Computer 

AWACS 

1 

(USA) 

DEC  Alpha  600 
AWACS 
Display  Console 
A:  UK 


DEC  Alpha  600 
AWACS 
Display  Console 
B:  FR 


OC-3 


DEC  Alpha  600 
AWACS 
Display  Console 
C:  GR 


LIS-4 

ELAN-4 


LlS-1,2,  3 
ELAN-1,2,3 


LIS-l 

ELAN-1 


LIS-l 

ELAN-1 


LlS-I 

ELAN-I 


V oice  over 
ATM 


100Base-T 

Ethernet 


DEC  Alpha  600 
AWACS 
Display  Console 
D:  IT 


LIS-l 

ELAN-1 


Figure  5.2:  ATM  Testbed  for  Integrated  Battlespace  Simulation 


5.3.  ATM  Network  Interface  Cards  Selection 

The  following  ATM  adapters  were  selected  for  each  workstation  platform  of  the 
battlespace  components: 

•  FORE  Systems  PCA-200EUX  ATM  adapter  for  PCI-bus  DEC  Alpha-600 
workstation. 

•  FORE  Systems  SBA-200E  ATM  adapter  for  S-bus  SUN  Sparc-20  workstation. 

•  FORE  Systems  VME-200  ATM  adapter  for  VME-bus  SGI  Onyx-1  workstation. 

The  ATM  adapter  provides  ATM  connectivity  for  host  systems  and  provides  the 
following  capabilities: 
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•  Supports  signaling  and  AAL  standards. 

•  Supports  for  SVCs  (through  UNI  3.0/3. 1  signaling)  and  PVCs. 

•  Provides  ATM  Classical  IP,  LAN  emulation,  and  SNMP. 

•  Provides  transparent  support  for  TCP/IP. 

•  Provides  ATM  Applications  Programmer  Interface  (API). 

5.4.  ATM  Network  Implementation 

Figure  5.4  shows  the  workstation  architecture  (corresponding  to  the  final  demonstration 
architecture  shown  in  Figure  4.3-2)  which  emphasizes  the  hardware  and  software 
components  related  to  ATM  connectivity.  Each  workstation  has  a  processor,  a  backplane 
communications  bus,  an  ATM  adapter,  device  driver,  protocol,  and  interface  software, 
and  an  operating  system.  In  addition,  it  is  planned  for  the  OSA  mission  computer  to  host 
the  ATM  network  management  software.  The  OSA  software  of  the  existing  Advanced 
AWACS  simulation  system  is  hosted  on  DEC  Alpha-600  workstations.  One  Alpha  acts 
as  the  OSA  mission  computer.  The  other  four  Alphas  act  as  the  OSA  display  consoles. 

The  Data  Exploitation,  Mission  Planning,  and  Communications  (DEMPC)  software  of 
the  existing  Advanced  AWACS  OSA  simulation  system  is  hosted  on  two  SUN  Sparc-20 
workstations.  One  SUN  acts  as  the  DEMPC  mission  planner  and  the  other  acts  as  the 
DEMPC  image  analyzer.  The  image  analyzer  and  mission  planner  SUN  Sparc-20 
workstations  have  S-Bus  slots  available  for  the  ATM  adapter. 

The  shooter  display  generator  software  is  hosted  on  one  Silicon  Graphics  Onyx-1  or  -2 
workstation.  This  Onyx  has  one  9U  VME  slot  available  and  a  VME  adapter  is  used  for 
the  baseline  ATM  interface.  It  is  important  to  note  that  the  portion  of  this  demonstration 
that  specifically  relates  to  on-board  the  O'*!  platform  itself  (i.e.,  OSA  mission  computer, 
display  console,  and  the  DEMPC  analyzer)  closely  approximates  a  real-life  scenario. 
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Figure  5.4:  Workstation  Architecture  Components 
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5.4.1.  Parts  List  for  ATM  Implementation 

The  equipments  and  components  required  for  the  demonstration  systems  include  two 
ATM  switches  with  multiple  OC-3  and  DS-3  ports,  an  ATM  LANE  module,  eight  ATM 
network  interface  cards  on  three  different  platforms,  various  optical  fibers  and  cables. 
The  parts  list  and  workstations  list  are  shown  in  Figure  5.4.1-1  through  Figure  5.4.1-3. 


Item 

Part  Description 

Part  Number 

Source 

Qty 

1 

ATM  switch  with  2  modules  of 
8  ports  OC-3;  PNNI/IISP 
feature;  ATM  Director;  H/W, 
S/W  upgrade  and  maintenance 

Lightstream 

LS-lOlO 

Cisco  Systems 
(206)  688-2204 

1 

2 

ATM  switch  LANE  module 
with  H/W  and  S/W  upgrade 
and  maintenance  support 

Catalyst  5000 

Cisco  Systems 
(206)  688-2204 

1 

3 

ATM  switch  with  2  modules  of 
8  ports  OC-3;  1  module  of  2 
DS-3  ports;  PNNI/IISP  and 
LANE;  ATM  Manager;  H/W, 
S/W  upgrade  and  maintenance 

Cellplex  7000 

3Com  Corp. 
(206)  450-4916 

1 

■ 

ATMworks  350  PCIbus  ATM 
adaptor  with  OC-3C 
with  LANE  (UNIX  4.0) 

DGLPB-AB 

Digital  Equipment 
Corp 

(206)  637-4263 

5 

5 

PCIbus  ATM  adaptor  with 
with  LANE  (UNIX  4.0) 

PCA- 

200EUX/OC3SC 

Fore  Systems 
(206)  655-6433 

■ 

6 

Sbus  ATM  adaptor  with  OC- 
3  C/SC  coimectors  and  SimOS 
&  Solaris  driver 

SBA- 

200E/OC3SC 

Fore  Systems 
(206)  655-6433 

2 

■ 

VMEbus  6U  ATM  adaptor 
with  OC-3C/SC  connectors 

VME- 

200/OC3SC-9U 

Fore  Systems 
(206)  655-6433 

■ 

8 

SC  to  SC,  62.5/125  pm 
multimode  fiber,  150  ft 

FOA6SC/6SC- 
62.5-PVC-150  ft 

Connect  Air 
(206)813-5599 

■ 

9 

SMAtoSC,  100/140  pm 
multimode  fiber,  50  ft 

FOA2SC/SMA- 
lOO-PVC-50  ft 

Connect  Air 
(206)813-5599 

2 

10 

DB-50P  to  DB-50P  SCSI 
cable,  6  ft 

654-1035-06 

Connect  Air 
(206)813-5599 

2 

Figure  5.4.1-1;  Parts  List  for  ATM  Network  Implementation 
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Property  and 
Serial  No. 

Description 

Model 

PB560-A9 

Media 

Memory 

39011518 

NT720034II 

Hammer;  OSA 

mission 

computer 

DEC 

AlphaStation 
500  5/400 

4.3  GB  disk  (qty  2) 

3.5”  floppy  drive 

4  mm  DAT  tape  drive 

128  MB 
Volatile 

39011525 

NT720034MQ 

Ryobi:  OSA 
display  console 

DEC 

AlphaStation 
500  5/400 

4.3  GB  disk 

3.5”  floppy  drive 

135  MB  Sy quest  drive 

128  MB 
Volatile 

39011526 

NT720034KO 

Delta:  OSA 
display  console 

DEC 

AlphaStation 
500  5/400 

4.3  GB  disk 

3.5”  floppy  drive 

135  MB  Syquest  drive 

128  MB 
Volatile 

39011517 

NT720034GE 

Punch:  OSA 
display  console 

DEC 

AlphaStation 
500  5/400 

4.3  GB  disk 

3.5”  floppy  drive 

135  MB  Syquest  drive 

128  MB 
Volatile 

39011527 

NT720034KM 

Bandsaw:  OSA 
display  console 

DEC 

AlphaStation 
500  5/400 

4.3  GB  disk 

3.5”  floppy  drive 

135  MB  Syquest  drive 

128  MB 
Volatile 

39011519 

NT720034HG 

Torx;  OSA 
display  console 

DEC 

AlphaStation 
500  5/400 

4.3  GB  disk 

3.5”  floppy  drive 

135  MB  Syquest  drive 

128  MB 
Volatile 

39011528 

NT720034JK 

Jigsaw:  OSA 
display  console 

DEC 

AlphaStation 
500  5/400 

4.3  GB  disk 

3.5”  floppy  drive 

135  MB  Syquest  drive 

128  MB 
Volatile 

Figure  5.4.1-2:  List  of  DEC  Alpha-500  Workstations 


Property  and 
Serial  No. 

Description 

Model 

PB620-A9 

Media 

Memory 

39010476 

NI546008V6 

USA:  OSA 

mission 

computer 

DEC  Alpha 
600  5/266 

39010478 

NI546008U4 

UK:  OSA 
display  console 

DEC  Alpha 
600  5/266 

39010144 

NI546008W8 

France:  OSA 
display  console 

DEC  Alpha 
600  5/266 

39010145 

NI546008XA 

Germany:  OSA 
display  console 

DEC  Alpha 
600  5/266 

39010146 

NI546008T2 

Italy:  OSA 
display  console 

DEC  Alpha 
600  5/266 

Figure  5.4.1-3:  List  of  DEC  Alpha-600  Workstations 
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5.4.2.  ATM  Adapter  Installation  Procedure 

The  installation  procedure  of  the  FORE  ATM  Network  Interface  Card  for  Digital  Unix 
4.0a  ForeThought  4.0.3(1 .3)  PCA-200E  Driver  is  described  in  this  section. 

FORE  ATM  Adapter  Installation  Procedure: 

Release  Notes:  ForeThought  4.0.3(1.3)  contains  support  for  the  tcpdump  utility. 

Be  sure  to  log  in  as  root. 

Set  the  EDITOR  environment  variable  to  point  to  your  favorite  editor. 

For  example: 

#  EDITOR=/usr/dt/bin/dtpad 

#  export  editor 

If  there  is  a  previous  version  of  the  FORE  driver  installed,  remove  it  from 
the  kemal  configuration  using  setld. 

#  setld  -d  <Build_Name> 

If  unsure  what  to  put  into  <Build_Name>,  use  the  output  of: 

#  setld  -i  I  grep  FORE  |  grep  installed  |  awk  '{print  $1 }' 

Now  install  the  driver. 

#  mkdir  /usr/tmp/fore 

#  cd  /usr/tmp/fore 

#  ftp  ftp.fore.com 
login:  ftp 

password:  <Your  email  address> 
ftp>  bin 

ftp>  cd  /priv/release/sunny 
ftp>  get  du_4.0.2_l .  1 9.tar.Z 
ftp>  bye 

#  uncompress  du_4.0.2_1.19.tar.Z 

#  tar  xvf  <filename>.tar 

#  cd  ..  /*  Change  directory  to  /usr/tmp/  */ 

#  setld  -1  fore 

/*  Installation  screen  capture  begins  here.  */ 
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***  Enter  subset  selections  *** 

The  following  subsets  are  mandatory  and  will  be  installed  automatically 
unless  you  choose  to  exit  without  installing  any  subsets: 

*  FORE  Systems,  Inc  PCA-200E 

You  may  choose  one  of  the  following  options: 

1 )  ALL  of  the  above 

2)  CANCEL  selections  and  redisplay  menus 

3)  EXIT  without  installing  any  subsets 

Enter  your  choices  or  press  RETURN  to  redisplay  menus. 

Choices  (for  example,  1  2  4-6):  1  /*  Choose  #1  */ 

You  are  installing  the  following  mandatory  subsets: 

FORE  Systems,  Inc  PCA-200E 

You  are  installing  the  following  optional  subsets: 

Is  this  correct?  (y/n):  y  /*  Answer  yes  */ 

1  subset(s)  will  be  installed. 

Loading  1  of  1  subset(s).... 

FORE  Systems,  Inc  PCA-200E 
Copying  from  fore  (disk) 

Verifying 

1  of  1  subset(s)  installed  successfully. 

Linking  /usr/opt/AFTBASE402/fore  to  /usr/fore 
Configuring  "FORE  Systems,  Inc  PCA-200E"  (AFTBASE402) 
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Would  you  like  to  use  FORE's  SNMP  agent?  [y] 

Would  you  like  to  use  the  standard  UDP  ports  for  SNMP(160/161)?  [y] 

Will  ILMI  be  used  for  Address  Registration?  [y] 

Would  you  like  to  configure  Classical  IP?  [n] 

Would  you  like  to  configure  qaaO?  [y] 

Enter  the  ATM  address  for  the  ARP  server 

47.01  .OO.OO.OO.OO.OO.OO.OO.OO.OO.OO.OO.OO.eO.  1 4.24.7f.0 1 .00 

Would  you  like  to  configure  qaal?  [y]  n 

Would  you  like  to  configure  qaa2?  [y]  n 

Would  you  like  to  configure  qaa3?  [y]  n 

Would  you  like  to  configure  LAN  Emulation?  [n] 

Next,  build  a  new  kemal  using  doconfig... 

#  doconfig. 

You  will  be  prompted  for  a  kernel  config  filename.  For  example,  "FORE_ATM" 

Choose  at  least  KDEBUG  and  CDFS  from  the  kemal  option  list.  When  it  asks 
you  if  you  want  to  edit  the  configuration  file,  answer  y. 

***  KERNEL  CONFIGURATION  AND  BUILD  PROCEDURE  *** 

Enter  a  name  for  the  kernel  configuration  file.  [TAC-ALPHAl]:  FORE_ATM 

A  configuration  file  with  the  name  'FORE  ATM'  already  exists. 

Do  you  want  to  replace  it?  (y/n)  [n];  y 

Saving  /sys/conf/FORE_ATM  as  /sys/conf/FORE_ATM.bck 


***  KERNEL  OPTION  SELECTION  *** 
Selection  Kernel  Option 


1  LAN  Emulation  over  ATM  (LANE) 

2  Classical  IP  over  ATM  (ATMIP) 

3  ATM  UNI  3.0/3. 1  Signalling  for  SVCs 

4  Asynchronous  Transfer  Mode  (ATM) 

5  Advanced  File  System  (ADVFS) 

6  System  V  Devices 

7  Logical  Volume  Manager  (LVM) 

8  Kernel  Breakpoint  Debugger  (KDEBUG) 

9  NTP  V3  Kernel  Phase  Lock  Loop  (NTP_TIME) 

1 0  Packetfilter  driver  (PACKETFILTER) 

1 1  Point-to-Point  Protocol  (PPP) 

1 2  STREAMS  pckt  module  (PCKT) 

1 3  X/Open  Transport  Interface  (XTISO,  TIMOD,  TIRDWR) 

14  File  on  File  File  System  (FFM) 

1 5  ISO  9660  Compact  Disc  File  System  (CDFS) 

1 6  Audit  Subsystem 

1 7  ACL  Subsystem 

1 8  Logical  Storage  Manager  (LSM) 

19  All  of  the  above 

20  None  of  the  above 

21  Help 

22  Display  all  options  again 


Enter  the  selection  number  for  each  kernel  option  you  want. 

For  example,  1  3  [20]:  8  15/*  KDBUG  and  CDFS  are  8  and  15  in  this  case  */ 

You  selected  the  following  kernel  options: 

Kernel  Breakpoint  Debugger  (KDEBUG) 

ISO  9660  Compact  Disc  File  System  (CDFS) 

Is  that  correct?  (y/n)  [yj:  y 

Do  you  want  to  edit  the  configuration  file?  (y/n)  [n]:  y 

Using  dtpad  to  edit  the  configuration  file.  Press  return  when  ready, 
or  type  'quit'  to  skip  the  editing  session: 
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At  this  point,  you  will  be  dropped  into  the  editor  defined  by  the 
SEDITOR  environment  variable. 

Before  the  first  'options'  line,  add  the  following  line: 

options  AFT403  ??? 

save  and  exit  from  the  editor... 

The  kernel  build  will  then  proceed. 

***  PERFORMING  KERNEL  BUILD  *** 

A  log  file  listing  special  device  files  is  located  in  /dev/M AKEDEV.log 
Working....Thu  Sep  26  15:21:29  EDT  1996 
Working....Thu  Sep  26  15:23:31  EDT  1996 

The  new  kernel  is  /sys/FORE_ATM/vmunix 
# 

When  it's  done, 

#  mv  /vmunix  /vmunix.pre_FORE  /*  optionally  save  the  orginal  kernel  */ 

#  cp  /sys/FORE_ATM/vmunix  /vmunix 

#  reboot 

During  bootup,  you  should  see  messages  to  the  effect  of: 

faO:  FORE  ATM  pca-200e 

Configuring  FORE  ATM 
fa:  waiting  for  firmware  download- 
fa:  firmware  download  complete 
faO:  200-series  operational 

These  messages  indicate  that  the  PCA-200E  was  recognized  and  the  firmware 
was  successfully  downloaded. 

(This  completes  the  driver  installation  process.) 

Once  rebooted,  login  as  root  and  configure  the  interface. 

For  FORE  IP  enter  a  command  similar  to: 

#  ifconfig  faO  169.144.160.68  netmask  255.255.255.0  up 
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For  Classical  IP,  enter  a  command  similar  to: 

•  ifconfig  qaaO  169.144.168.68  netmask  255.255.255.0  up 

For  LAN  Emulation: 

•  /usr/fore/etc/configure_lanem  /*  See  the  User's  Manual  for  instructions  */ 

•  ifconfig  elO  up 

In  order  to  permantly  preserve  IP  configuration  during  reboots,  run 
/usr/sbin/netsetup  as  described  in  chapter  4  of  the  Digital  Unix  PCA-200E 
User's  Manual. 

Summary: 

•  Install  the  NIC 

•  Install  the  software  subset: 

setld  -1  /apps/Special/fore  AFTBASE402 

•  Configure  FORE  ATM  Adapter 

Would  you  like  to  use  FORE's  SNMP  agent?  [y]  y 

Would  you  like  to  use  the  standard  UDP  ports  for  SNMP(160/161)?  [y]  y 

Will  ILMI  be  used  for  Address  Registration?  [y]  y 

Would  you  like  to  configure  Classical  IP?  [n]  y 

Would  you  like  to  configure  qaaO?  [y]  y 

Enter  the  ATM  address  for  the  ARP  server 

47.01.00.00.00.00.00.00.00.00.00.00.00.00.e0.14.24.7f01.00 

Would  you  like  to  configure  qaal?  [y]  n 

Would  you  like  to  configure  qaa2?  [y]  n 

Would  you  like  to  configure  qaa3?  [y]  n 

Would  you  like  to  configure  LAN  Emulation?  [n]  y 

•  Rebuild  the  kernel: 
setenv  EDITOR  vi 
setenv  VISUAL  vi 
doconfig 

•  When  it  asks  if  you  want  to  edit  the  config  file,  answer  yes 
and  add  the  following  options  line: 

options  AFTBASE402 

•  Install  the  new  kernel  and  reboot. 
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Note:  At  this  point,  the  Fore  commands  are  in  /usr/fore/etc/ 

•  Run  netsetup  and  configure  qaaO. 

•  Alternative  method,  assuming  system  previously  had  exactly  1  interface: 

echo  "137.136.33.35  belugafd  atmipaddr" » /etc/hosts 
echo  "137.136.33.250  atmswitch" »  /etc/hosts 
echo  "137.136.33.251  mcast-dest-IP-addr" » /etc/hosts 
rcmgr  set  NUM_NETCONFIG  2 
rcmgrsetNETDEV_l  "qaaO" 

rcmgr  set  IFCONFIG  I  "atmipaddr  netmask  255.255.255.0" 

•  Associate  a  PVC  for  qaaO: 

Note  that  this  will  need  to  be  added  to  a  startup  script. 

/usr/fore/etc/atmarp  -c  mcast-dest-IP-addr  qaaO  0  255  0 

•  Enable  IP  aliasing: 

(******  This  will  need  to  be  added  to  a  startup  script  *******) 
ifconfig  qaaO  alias  mcast-dest-IP-addr  netmask  255.255.255.0 

•  Test  qaaO: 

ping  atmipaddr 
ping  atmswitch 
ping  [something  else] 

/usr/fore/etc/atmarp  -a 

•  Configure  LANE: 

(Note:  The  first  two  lines  are  in  lieu  of  running  the  configure  lanem  script.) 

echo  "LECS_NSAP_ADDR=-wellknown;  export  LECS_NSAP_ADDR"  > 
/usr/fore/etc/fore_lanem.conf 

echo  "DEFAULT_ELAN="default";  export  DEFAULT_ELAN"  » 
/usr/fore/etc/fore_lanem.conf 

echo  "137.136.41.35  belugaelan" » /etc/hosts 
rcmgr  set  NUM_NETCONFIG  3 
rcmgr  set  NETDEV_2  "elO" 

rcmgr  set  IFCONFIG_l  "belugaelan  netmask  255.255.255.0" 
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Test  elO: 


/usr/fore/etc/elconfig  show  -all 
ping  belugaelan 
ping  [something  else] 

Notes: 

-  If  the  switch  changes,  you'll  need  to  enter  a  new  NSAP  address 
into  /usr/fore/etc/fore_atm.config  for  RFC  1577  to  work. 

-  The  subset  install  process  sets  up  /sbin/init.d/foreatm,  which 
configures  things  based  on  /usr/fore/etc/fore_atm.config  and 
/usr/fore/etc/fore  lanem.conf. 
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5.4.3.  ATM  Adapter  Installation  Problems 

DEC  Alpha  500  workstations  were  not  compatible  with  FORE  Systems’  PCI-bus  ATM 
adapters  (ForeRunner  PCA-200E),  resulting  in  serious  ATM  integration  problems. 
Several  of  the  problems  that  were  encountered  are  summarized  here. 

Workstation  1  (Hostname:  Punch):  Among  the  five  Alpha  500  workstations  delivered  to 
the  ITDL,  one  station  (hostname:  Punch)  was  assembled  with  an  old  circuit  board  and  old 
Firmware  (version  3.8)  while  the  rest  were  assembled  with  new  circuit  boards  and  new 
Firmware  (version  3.9).  When  FORE’s  ATM  adapters  were  installed  into  all  five 
stations,  the  Punch  station  came  up  with  no  apparent  problems,  but  the  rest  of  the  stations 
didn’t  come  up  at  all. 

Workstation  2  (Hostname:  Tone):  This  station  didn’t  come  up  initially.  After  running  a 
series  of  status  commands,  the  FORE’s  ATM  adapter  suddenly  started  working.  After 
rebooting  the  workstation,  it  still  came  up  just  fine.  At  this  time  no  clear  explanation  can 
be  provided  why  it  started  working. 

Workstation  3  (Hostname:  Rvobil:  This  station  didn’t  come  up  at  all.  The  problem  was 
that  the  Firmware  v.3.9  was  not  downloaded  to  the  ATM  card.  After  getting  the 
Firmware  downloaded  manually,  it  was  discovered  that  the  FORE’s  SNMP  daemon 
(snmpd)  was  not  running.  Apparently,  the  FORE  ATM  adapter  kills  DEC’S  SNMP 
daemon  and  reloads  its  own  snmpd,  but  it  does  not  run  the  snmpd.  After  starting  the 
snmpd  manually,  we  still  cannot  join  the  ATM  ELAN.  This  problem  was  resolved  by 
removing  the  existing  ELAN,  reconfiguring  the  temporary  “default  ELAN,”  and 
reinitializing  the  interface  with  the  IFCONFIG  command.  This  station  (Ryobi) 
successfully  joined  the  ELAN  and  the  ATM  LAN  emulation  was  operational. 

Workstation  4  (Hostname:  Hammer):  The  same  procedure  used  in  the  workstation  3  was 
tried  to  fix  the  Hammer  station.  It  came  back  with  an  error  message  of  having  a 
duplicate  MAC  address,  so  it  would  not  allow  it  to  join  the  ELAN.  Apparently,  we 
needed  to  set  up  a  temporary  “default  ELAN.”  With  this  default  ELAN  set  up,  the  ATM 
card  was  enabled  to  come  up  and  successfully  joined  the  ELAN. 

Workstation  5  (Hostname:  Bandsaw):  The  same  procedure  used  in  workstation  4  fixed 
the  Bandsaw  station. 

After  getting  all  stations  up  manually,  another  problem  arose;  the  system  would  not  come 
up  to  the  users  accounts.  After  trouble-shooting,  it  was  found  that  when  we  brought  the 
system  up  manually,  the  system  lost  the  fix  that  enabled  the  card  to  come  up  at  system 
initialization.  This  was  done  by  hacking  FORE’s  startup  scripts.  However,  this  fix  was 
only  temporary  and  each  individual  workstation  could  not  be  made  consistently 
operational;  it  only  worked  randomly. 
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Punch  DEC  500  workstation  has  the  following  software  version: 

SRM  Console;  V6.3-1 1 
ARC:  4.49 

Palcode:  VMS  palcode  VI.  18-0,  OSF  Palcode  VI. 2 1-0 
SROM  Version:  V2.05 

Motherboard  has  21 164-1  DEC  ALPHA  CHIP 

This  system  recognizes  the  FORE  Systems  ATM  card  and  loads  firmware  correctly. 


All  other  remaining  DEC  500s  have  the  following  software  versions: 

SRM  Console:  V6.4-5  Feb  21,  1997 
ARC:  4.52 

Palcode:  VMS  palcode  VI.  18-0,  OSF  Palcode  VI. 2 1-0 
SROM  Version:  V2.05 

Motherboards  have  2 1 1 64-2  DEC  ALPHA  CHIP 

These  systems  do  not  work  with  FORE  Systems  ATM  cards. 

5.4.4.  ATM  Adapter  Installation  Problems  Fix 

All  hardware  for  the  five  new  Digital  Equipment  Corporation  (DEC)  Alpha-500 
workstations  was  assembled  in  the  unclassified  area  of  the  D-1  Lab,  while  the  existing 
DEC  Alpha-600  workstations  were  already  set  up  in  the  classified  area  of  the  D-1  Lab  of 
the  ITDL.  The  FORE  Systems’  ATM  Network  Interface  Cards  (NIC)  were  installed  into 
the  new  DEC  Alpha-500  workstation.  However,  the  ATM  NICs  were  not  properly 
functional  due  to  the  driver  softwaire  incompatibility  with  a  new  DEC  Alpha-500 
workstation.  It  was  found  that  the  FORE  Systems’  ATM  NICs  (PCA-200  ATM  PCI-bus 
adapter  for  DEC  Alpha)  did  not  support  a  newer  model  of  DEC  Alpha-500  workstation. 
The  approaches  we  undertook  to  address  the  problems  were  as  follows: 

a)  First,  we  tried  to  debug  the  problems  associated  with  FORE’s  ATM  NICs  on  DEC 
Alpha-500  workstations.  This  debugging  effort  was  partially  successful  and  we  could 
make  each  workstation  operational  (as  described  in  section  5.4.3)  but  only  in  a  certain 
timing  condition.  It  was  not  consistently  working  and  required  frequent  rebooting. 
The  rebooting  procedure  was  not  normal  and  was  very  complicated.  In  addition, 
FORE  Systems  would  not  support  ATM  NICs  for  the  DEC  Alpha-500  workstation. 

b)  Second,  we  tried  DEC’S  own  ATM  NICs  (ATMWork  350  adapter)  on  the  DEC 
Alpha-500  stations  and  they  did  not  work,  either.  The  ATM  NICs  for  a  newer  model 
of  the  Alpha-500  workstation  were  not  yet  available  even  within  DEC. 

c)  Third,  we  tried  the  FORE’s  ATM  NICs  on  DEC  Alpha-600  workstations  and  verified 
that  FORE’s  ATM  NICs  were  functional  with  DEC  Alpha-600  workstations. 
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d)  Fourth,  we  verified  that  the  FDDI  NICs  were  compatible  with  new  DEC  Alpha  500 
workstations.  One  of  the  AWACS  systems  in  the  classified  area  would  remain  in  the 
FDDI  configuration  for  a  while. 

Following  a  month-long  debug  procedure,  we  decided  to  exchange  the  new  DEC  Alpha- 
500  workstations  in  the  unclassified  area  with  the  existing  DEC  Alpha-600  workstations 
of  the  AWACS  demonstration  system  in  the  classified  area.  Since  DEC  Alpha-600 
workstations  were  functional  with  FORE  ATM  NICs  while  DEC  Alpha-500  workstations 
were  operational  with  FDDI  NICs,  we  swapped  DEC  Alpha-500  with  Alpha-600  for  the 
proper  operation  of  both  systems.  After  the  workstation  exchange,  the  ATM  network  was 
immediately  functional  with  the  same  FORE’s  ATM  NICs  that  allowed  us  to  start  the 
benchmarking  test.  Besides,  the  FDDI  network  was  also  functional  with  DEC  Alpha-500 
workstations  in  the  classified  area  of  D-1  Lab,  which  allows  for  ITDL’s  day-by-day 
Advanced  AWACS  demonstration. 

05/29/97:  DEC  Alpha  500  workstations  received. 

06/03/97:  DEC  engineer  installed  DEC  Alpha  500s. 

06/05/97:  Discovered  a  problem  of  DEC  Alpha  500s  with  FORE’s  ATM  adapter. 

06/06/97:  DEC  engineer  completed  repairs  to  a  DEC  Alpha  500 

-  PUNCH  workstation  replaced  the  motherboard. 

06/1 0/97:  Determined  DEC  Alpha  500's  incompatibility  with  FORE’s  ATM  adapter. 

Note:  Punch  workstation’s  motherboard  replaced  due  to  a  SCSI  problem. 
06/19/97 :  Decided  to  swap  DEC  Alpha  500s  with  DEC  Alpha  600s. 

06/20/97:  FORE’s  ATM  adapter  worked  well  with  DEC  Alpha  600  workstations. 

Problem  with  DEC  Alpha  500s  did  not  occur  with  DEC  Alpha  600s. 
06/23/97:  Requested  FORE  Systems  to  resolve  the  problem  on  the  DEC  Alpha  500s. 

Asked  if  FORE’s  ATM  adapter  would  support  DEC  Alpha  500s  and  also 
asked  about  any  known  problems  if  the  adapter  would  not  support  the 
DEC  Alpha  500s.  FORE  Systems  was  not  aware  of  any  issues. 

06/30/97:  Received  a  response  from  FORE  Systems.  Fore  Systems  became  aware  of 

the  problem.  FORE  Systems  neither  supports  DEC  Alpha  500s  nor  has 
any  future  plans  to  support  it. 

Note:  This  incompatibility  issue  was  revisited  later  during  the  final  system  integration. 
However,  at  the  time  of  final  demonstration,  the  proper  ATM  adapters  were  still  not 
available  for  DEC  Alpha-500  workstation.  Therefore,  the  FDDI  network  with  DEC 
Alpha-500  workstations  could  not  be  migrated  to  ATM.  The  one  option  is  to  use  LAN 
Emulation  (LANE)  through  FDDI  LAN  switch  since  the  latest  LANE  technology 
supports  FDDI. 
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6. 


SYSTEM  TEST  AND  PERFORMANCE  EVALUATION  (TASK  3) 


One  of  the  important  objectives  of  this  program  was  to  evaluate  the  performance  of  an 
Asynchronous  Transfer  Mode  (ATM)  backbone  network  designed  to  replace  the  existing 
FDDl/Ethemet  networks  for  the  Advanced  AW  ACS  mission  avionics  systems.  The  test 
plan  addressed  ATM  switch  test,  switch  interoperability  test,  multicast  configuration  test, 
and  performance  evaluation  test  of  ATM-based  Advanced  AWACS  interim 
demonstration  subsystems.  The  subsystem  evaluation  test  had  two  components;  One  was 
an  ATM  network  performance  test  such  as  throughput,  latency,  and  cell  loss;  the  other 
was  an  application  performance  test  using  an  AWACS  application  program. 

The  AWACS  mission  computer  uses  client/server  displays.  These  client/server  displays 
were  demonstrated  to  ensure  that  ATM  would  handle  the  client/server  messaging 
protocol  in  a  manner  that  is  required  for  a  real-time  command  and  control  system.  The 
transmission  of  real  time  messages  and  the  network  performance  were  investigated.  The 
Ping  and  Bing  (Bandwidth  Ping)  were  used  for  verification  of  network  connection  and 
the  Netperf  (Network  Performance  Benchmark)  and/or  NTTCP  (Network  Trivial 
Transmission  Control  Protocol)  software  tools  were  used  to  investigate  the  traffic  loading 
impact  on  ATM  network  performance.  The  AWACS  network  performance  measure  was 
focused  on  the  maximum  achievable  throughput. 

The  AWACS  application  benchmark  test  addressed  the  ATM  protocol’s  ability  to  handle 
the  volume  of  data  between  the  mission  computers  and  the  display  consoles.  The  current 
method  of  transmitting  the  tracks  and  sensor  data  to  the  consoles  involved  using  UDP  in 
the  broadcast  mode  for  data  that  are  common  to  all  consoles.  This  technique  allows  more 
consoles  to  be  added  to  the  system  with  only  a  minor  impact  to  LAN  loading.  Since  the 
future  AWACS  is  to  be  designed  for  significant  numbers  of  display  consoles,  this  is  a  key 
feature  that  should  be  investigated  for  the  ATM  implementation.  The  application 
performance  measure  was  focused  on  the  network,  mission  computer,  and  display 
consoles  loading  effects. 

The  test  report  was  divided  into:  (1)  ATM  switch,  interoperability,  and  application 
program  test,  (2)  ATM  multicast  configuration  test,  (3)  ATM/FDDI  network  benchmark 
test,  and  (4)  ATM/FDDI  application  benchmark  test. 

6.1.  ATM  Switch,  Interoperability,  Application  Program  Test 

Among  commercially  available  products,  three  ATM  switches  from  Cisco  Systems, 
FORE  Systems,  and  3Com  Corporation  were  down-selected  in  this  program  for  the 
Integrated  Battlespace  Simulation  (IBS)  demonstration.  The  down-selection  was  based 
on  the  trade  study  that  includes  functional  features,  performance  data  (Figure  6.1.1), 
technical  support,  future  growth  for  upgrade,  and  cost.  The  Cisco  LS-lOlO  ATM  switch 
was  selected  in  the  first  place,  then  the  Fore  ASX-200BX  switch,  and  the  3Com  Cellplex 
7000  switch  as  a  backup.  Both  the  Cisco  LS-lOlO  and  FORE  ASX-200BX  switches 
were  implemented  for  the  Advanced  AWACS  platforms  at  the  ITDL  and  the  Kent  OSA 
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Lab,  respectively.  The  3Com  switch  would  be  used  as  necessary  for  ATM  port  expansion 
to  connect  the  AWACS  platform  with  the  UAV  ground  station  and  the  advanced  fighter 
station,  in  the  remote  (not  co-located)  laboratory  within  the  ITDL  facilities.  Figure  6.1 
shows  a  LAN  Emulation  (LANE)  Broadcast  and  Unknown  Server  (BUS)  throughput 
comparison  among  various  vendors’  ATM  switches. 


LANE  BUS 


Throughput 

(kpps) 


Throughput  Test 


*Module  not  currently  available 
(Source:  Data  Communications,  September  1996) 


Figure  6.1:  ATM  LANE  BUS  Throughput  Comparison 


There  are  two  different  approaches  for  ATM  connection  in  LAN  environments:  (1)  native 
mode  ATM  technology  and  (2)  emulated  mode  ATM  technology.  In  any  case,  some 
protocols  (e.g..  Intersubnet  Protocol)  allow  for  direct  communications  between  different 
logical  subnets  as  well  as  within  its  own  logical  subnet,  while  others  (e.g..  Intrasubnet 
Protocols)  work  only  within  their  own  logical  IP  subnet,  so  they  require  a  separate  router 
for  communications  between  different  logical  subnets.  In  the  native  mode  ATM 
technology,  there  are  three  major  intrasubnet  protocols:  (1)  Classical  IP  and  ARP  over 
ATM  (RFC  1577),  (2)  IP  multicasting  MARS  over  ATM  (RFC  1 1 12),  (3)  Multiprotocol 
encapsulation  over  ATM  AAL-5  (RFC  1483),  and  an  emerging  Internet  Engineering  Task 
Force  (IETF)  intersubnet  protocol,  i.e..  Next  Hop  Resolution  Protocol  (NHRP).  Note  that 
the  Request  For  Comment  (RFC)  document  is  prepared  for  the  IETF  standard.  Similarly, 
in  the  emulated  mode  ATM  technology,  there  is  an  intersubnet  protocol,  ATM  LAN 
emulation,  and  an  emerging  ATM  Forum  intrasubnet  protocol,  Multi-Protocol  Over  ATM 
(MPOA). 
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Currently,  only  two  major  approaches  of  ATM  LANE  and  classical  IP  over  ATM  (RFC 
1577)  are  available  as  commercial  products.  Therefore,  to  establish  connectivity  among 
IBS  subsystems  (e.g..  Advanced  AWACS,  UAV  ground  station,  and  fighter  stations)  the 
ATM  LANE  and  the  Classical  IP  over  ATM  approaches  were  adopted.  However,  the 
classical  IP  over  ATM  protocol  does  not  support  a  multicasting  (broadcasting)  capability, 
while  the  ATM  LANE  protocol  does.  Thus,  the  point-to-multipoint  Permanent  Virtual 
Circuits  (PVC)  connections  were  set  up  at  the  ATM  switch,  then  classical  IP  over  ATM 
were  run  over  Switched  Virtual  Circuits  (SVC)  for  point-to-point  TCP  unicast  and  over 
permanent  virtual  circuits  for  point-to-multipoint  UDP  multicast. 

LAN  emulation  becomes  a  standard  ATM  service  that  provides  interoperability  between 
ATM-based  devices  and  existing  legacy  LAN-based  devices.  The  function  of  the  LANE 
protocol  is  to  emulate  the  local  area  networks  (e.g.,  Ethernet,  Token  Ring)  on  top  of  an 
ATM  network;  in  other  words,  it  resolves  the  Medium  Access  Control  (MAC)  addresses 
into  ATM  addresses.  Since  the  LANE  serviee  presents  the  same  service  interface  of 
existing  MAC  protocols  to  the  network  layer,  it  requires  no  modifications  to  higher  layer 
protocols  for  its  operation  over  an  ATM  network.  The  important  LANE  components 
include  LAN  Emulation  Client  (LEC),  LAN  Emulation  Server  (LES),  Broadcast  and 
Unknown  Server  (BUS),  and  LAN  Emulation  Configuration  Server  (LECS). 

The  switch  cell  latency  is  considered  insignificant  compared  with  overall  system  delay. 
In  this  section,  the  interoperability  test,  LANE  BUS  throughput  test,  and  software 
compatibility  test  between  UNIX  4.0  AWACS  application  program  and  LANE  1.0 
program  are  described. 
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6.1.1.  Switch  Interoperability  Test 

A.  Objective: 

To  verify  an  interoperability  among  different  vendors’  ATM  switches  since  the  three 
different  switches  of  Cisco  Systems,  FORE  Systems,  and  3Com  Corporation  will  be  used 
in  one  way  or  another  for  the  Integrated  Battlespace  Simulation  (IBS)  demonstration. 
The  Cisco  switch  and  FORE  switch  (in  Kent  OSA)  were  used  for  Advanced  AWACS 
platforms,  and  the  3Com  switch  was  used  for  ATM  port  expansion,  as  necessary, 
depending  on  a  revised  network  architecture,  to  connect  the  AWACS  platform  with  the 
UAV  ground  station  and  advanced  fighter  station.  Since  compliance  with  ATM  Forum 
standards  does  not  necessarily  guarantee  full  ATM  interoperability  or  ease  of  integration 
with  existing  devices,  it  is  worthwhile  to  verify  the  interoperability  prior  to 
implementation  of  ATM  networks. 

B.  Approach: 

The  LAN  emulation  and  Classical  IP  over  ATM  configurations  were  used  to  determine 
the  switch’s  interoperability  (Figure  6.1.1).  ATM  LANE  service  was  configured  in  one 
of  the  Cisco  Catalyst-5000  LAN  switches,  their  OC-3  uplinks  were  connected  to  Cisco 
LS-lOlO  ATM  switch,  then  the  Cisco  ATM  switch  (network  side)  was  connected  through 
PNNI-0  (IISP)  to  a  3Com  switch  or  FORE  switch  (user  side).  The  ATM  Address 
Resolution  Protocol  (ATMARP)  for  classical  IP  over  ATM  protocol  was  configured  in 
the  Cisco  ATM  switch.  Two  SUN  workstations  (LANE  clients)  were  connected  to  each 
ATM  switch;  one  to  the  Cisco  switch  and  another  to  the  3Com  switch.  Two  SGI 
workstations  were  connected  through  Fast  Ethernet  (100Base-T)  ports  to  each  of  the 
Cisco  Catalyst-5000  LAN  switches.  The  configuration  allowed  us  to  test  communications 
between  all  possible  combinations  of  ATM-attached,  LAN-attached,  or  ATM-LAN 
attached  clients  as  well  as  the  switch  interoperability  between  different  vendors. 

C.  Test  Items: 

•  Switch  interoperability  test  in  LANE  and  classical  IP  configurations. 

•  Communications  between  ATM-attached,  LAN-attached,  or  ATM  LAN  clients. 

D.  Test  Procedure: 

a)  Configure  a  Cisco  Catalyst-5000  LAN  switch  as  LES,  BUS,  and  LECS. 

b)  Connect  the  Cisco  Catalyst-5000  LAN  switch  to  Cisco  ATM  switch  (via  OC-3  link). 

c)  Configure  the  Cisco  LS- 1 0 1 0  ATM  switch  as  ATMARP. 

d)  Configure  the  Cisco  switch  as  IISP  network  and  the  3Com  switch  as  IISP  user. 

e)  Connect  the  Cisco  ATM  switch  to  the  3Com  switch. 

f)  Connect  two  SUN  workstations  (LECs)  to  each  of  Cisco  and  3Com  ATM  switches. 

g)  Connect  another  Cisco  Catalyst-5000  LAN  switch  to  Cisco  ATM  switch  (via  OC-3). 

h)  Connect  Fast  Ethernet  to  both  Cisco  Catalyst-5000  LAN  switches  (via  100Base-T). 

i)  Connect  two  SGI  workstations  to  each  of  the  Cisco  Catalyst-5000  LAN  switches. 

j)  Verify  if  the  clients  between  ATM-attached,  LAN-attached,  or  ATM-LAN  attached 
can  communicate  to  each  other  through  LANE  and  classical  IP  over  ATM  services. 
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Figure  6.1.1:  Switch  Interoperability  Test  Configuration 


E.  Expected  Results: 

With  LANE  and  Classical  IP  over  ATM  services,  all  possible  combinations  of  clients 
should  be  able  to  communicate  v\dth  each  other  on  the  ATM  interface  through  the  Cisco 
and  3Com  switches. 
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6.1.2.  LAN  Emulation  BUS  Throughput  Test 

A.  Objective: 

To  verify  the  Broadcast  and  Unknown  Server  (BUS)  throughput  of  various  vendors’ 
ATM  switches.  The  BUS  is  responsible  for  forwarding  all  broadcast/multicast  and 
unknown  destination  unicast  frames  (received  from  members  of  the  ELAN)  to  all 
members  of  the  ELAN.  The  LANE  BUS  throughput  test  (Figure  6.1.2-1)  measures  the 
ability  of  a  BUS  to  forward  frames.  According  to  AWACS  requirements,  the  ATM  LAN 
Emulation  (LANE)  BUS  should  be  able  to  meet  a  minimal  throughput  of  40  Mbps  of 
multicasting  data  to  multiple  display  consoles.  In  addition,  since  a  single  BUS  may  be 
used  for  multiple  ELANs,  the  need  for  a  high  throughput  BUS  is  increased. 


ATM  LANE  BUS  Throughput  Test 


Figure  6.1.2-1:  Conceptual  Diagram  of  LANE  BUS  Function 


B.  Approach: 

The  BUS  performance  strongly  influences  the  overall  performance  and  scalability  of 
LANE  networks.  In  order  to  avoid  the  interleaving  of  cells  of  different  frames  during 
forwarding,  which  is  not  permitted  for  AAL5  Protocol  Data  Units  (PDU),  the  BUS  must 
serialize  the  received  frames  prior  to  forwarding.  This  serialization  requires  a  reassembly 
of  incoming  frames  and  a  subsequent  segmentation  of  the  frames  prior  to  forwarding.  As 
a  result,  the  performance  of  the  SAR  on  the  BUS  is  the  most  significant  factor  affecting 
overall  BUS  performance.  Given  the  fact  that  some  BUS  implementations  perform  the 
SAR  in  software,  while  others  provide  it  in  hardware,  BUS  performance  varies 
tremendously. 
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ATM  LANE  BUS  performance  was  tested  by  sending  a  stream  of  broadcast  frames  to  the 
BUS,  using  an  Ethernet  frame  generator  and  monitoring  the  frames  forwarded  from  the 
BUS.  The  LANE-capable  LAN  switches  are  used  to  send  the  frames  to  the  BUS  which 
in  turn  forwards  the  frames  back  to  the  LAN  switches  (Figure  6. 1.2-2).  The  SmartBits 
Analyzer  (NetCom)  was  used  for  an  Ethernet  frame  generator  and  its  traffic  monitor. 
This  test  could  measure  the  broadcast  forwarding  rate  over  ATM-emulated  LANs. 


ATM  LANE  BUS  Throughput  Test 


Figure  6.1.2-2:  BUS  Throughput  Test  Configuration 


C.  Test  Items: 

•  LANE  throughput 

D.  Test  Procedure: 

a)  Build  an  Ethernet  frame  (64  B)  with  a  broadcast  destination  MAC  address. 

b)  Configure  multiple  Ethernet  interfaces  to  transmit  the  frames  at  a  100-Mbps  rate. 

c)  Configure  multiple  Ethernet  interfaces  to  monitor  the  frames  received. 

d)  Start  [he  Ethernet  frame  generator  on  the  input  ports  and  the  monitor  on  the  output 
ports. 

e)  Observe  the  received  packet  rate  and  the  transmitted  packet  rate,  both  per  second. 

E.  Expected  Results: 

The  ATM  switch  had  a  BUS  throughput  of  greater  than  60-Mbps  broadcast  depending  on 
the  Maximum  Transmission  Unit  (MTU)  size;  about  60  Mbps  with  an  MTU  size  of  64 
Byte  and  132  Mbps  with  an  MTU  size  of  1.5  kByte  (Figure  6. 1.2-3). 
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Figure  6.1.2-3:  LANE  BUS  Throughput  (Cisco  ATM  LAN  Switch) 
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6.1.3.  AWACS  Program  Run  Test 

A.  Objective: 

To  verify  a  functionality  of  Advanced  AWACS  application  programs  (e.g.,  mission 
computer  programs)  on  the  DEC  Alpha  workstation  (AWACS  platform).  The  DEC 
Alpha  workstation  required  digital  Unix  4.0  to  run  ATM  LAN  Emulation  (LANE).  Thus, 
the  current  digital  Unix  3.2x  should  be  upgraded  to  Unix  4.0.  The  software  compatibility 
of  ATM  LANE  1.0  with  Unix  4.0  had  to  be  verified  for  proper  AWACS  application 
programs  function. 

B.  Approach: 

First  of  all,  the  current  digital  Unix  3.2x  was  upgraded  to  Unix  4.0.  Then,  the  Advanced 
AWACS  mission  computer  programs  were  operating  on  ATM  switches  in  LAN 
Emulation  configuration  with  two  DEC  Alpha  workstations.  The  AWACS  program 
functionality  test  (Figure  6.1.3)  was  performed  in  point-to-point  TCP,  point-to-point 
UDP,  and  point-to-multipoint  UDP  multicast  modes. 

C.  Test  Items: 

•  Point-to-point  TCP. 

•  Point-to-point  UDP. 

•  Point-to-multipoint  UDP  multicast. 

D:  Test  Procedure: 

a)  Configure  ATM  switch  in  LAN  emulation  mode. 

b)  Configure  two  DEC  Alpha  workstations  as  LANE  clients  and  designate  one  as  a 
mission  computer  and  the  other  as  a  display  console. 

c)  Verify  the  ATM  LANE  network  functionality  using  “PING”  test  program. 

d)  Run  AWACS  application  program  (Unix  4.0)  on  a  mission  computer  in  a  point-to- 
point  TCP  mode. 

e)  Verify  a  proper  functionality  of  AWACS  application  program  on  a  display  console. 

f)  Run  AWACS  application  program  (Unix  4.0)  on  a  mission  computer  in  a  point-to- 
point  UDP  mode. 

g)  Verify  a  proper  functionality  of  AWACS  application  program  on  a  display  console. 

h)  Run  AWACS  application  program  (Unix  4.0)  on  a  mission  computer  in  a  point-to- 
multipoint  UDP  multicast  mode. 

i)  Verify  a  proper  functionality  of  AWACS  application  program  on  a  display  console. 

E.  Expected  Results: 

The  advanced  AWACS  mission  computer  programs  were  properly  operating  in  the  point- 
to-point  TCP,  point-to-point  UDP,  and  point-to-multipoint  UDP  multicast  modes  over  the 
ATM  LAN  Emulation  configuration  with  two  DEC  Alpha  workstations. 
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Figure  6.1.3:  AWACS  Program  Run  Test  Configuration 


6.2.  ATM  Multicast  Configuration  Test 

The  Advanced  AWACS  network  architecture  and  application  programs  require  not  only 
unicast  but  also  multicast  capability  for  the  distribution  of  data.  The  unicast  is  based  on 
TCP/IP  protocol  and  is  used  for  operator-related  activities  such  as  action  entries, 
alerts/alarms,  and  database  edits  between  the  Mission  Computer  (MC)  and  Display 
Consoles  (DC).  The  multicast  is  based  on  UDP/IP  protocol  and  used  for  common  data 
broadcasting  to  all  consoles  within  a  multicast  group  on  a  periodic  basis.  The  Advanced 
AWACS  applications  will  use  a  network  message  to  broadcast  databases  from  the  MC  to 
all  of  the  DCs,  send  alarms  to  specific  DCs,  or  send  action  entries  from  DC  to  MC. 

In  the  network  point  of  view,  a  multicast  allows  multiple  end  systems  to  receive  data 
from  and  transmit  data  to  other  multiple  systems.  Such  capability  is  easy  to  implement  in 
shared-media  technologies  such  as  LANs,  but  not  easy  in  the  connection-oriented  ATM 
technology.  The  analogy  in  ATM  to  a  multicast  LAN  group  would  be  a  bi-directional 
multipoint-to-multipoint  connection.  This  obvious  solution  cannot  be  implemented  when 
using  AAL-5  because,  unlike  AAL-3/4,  it  does  not  allow  for  interleaving  of  cells  from 
different  AAL-5  packets  on  a  single  connection.  This  means  that  all  AAL-5  packets 
across  a  particular  connection  must  be  received  in  sequence  at  destinations  with  no 
interleaving  between  the  cells  of  different  packets  on  the  same  connection.  The  following 
three  potential  solutions  have  been  proposed  to  address  the  problem;  (1)  multicasting  by 
multipoint-to-multipoint  virtual  path  connections,  (2)  multicasting  by  multicast  server, 
and  (3)  multicasting  by  overlaid  point-to-multipoint  connections. 

(1)  Virtual  Path  Connections:  In  this  approach,  a  multipoint-to-multipoint  virtual  path 
links  all  nodes  in  the  multicast  group  and  each  node  is  given  a  unique  VCI  value.  The 
interleaved  packets  can  be  identified  by  the  unique  VCI  value  of  the  source.  This 
mechanism  requires  a  protocol  to  allocate  VCI  values  to  nodes;  such  a  mechanism  does 
not  currently  exist. 

(2)  Multicast  Server  Operation:  All  nodes  set  up  a  point-to-point  unidirectional 
connection  with  a  multicast  server.  The  multicast  server  is  then  connected  to  all  nodes 
through  a  point-to-multipoint  connection.  The  multicast  server  receives  packets  across 
the  point-to-point  connection,  and  then  retransmits  them  across  the  point-to-multipoint 
connection,  but  only  after  ensuring  that  the  packets  are  serialized.  In  this  way,  cell 
interleaving  is  precluded.  ATM  LAN  emulation  currently  supports  only  Broadcast  and 
Unknown  Server  (BUS)  operation. 

(3)  Overlaid  Point-to-Multipoint  Connections:  In  this  mechanism,  each  node  in  the 
multicast  group  establishes  a  point-to-multipoint  connection  with  each  of  the  other  nodes 
in  the  group.  Thus,  all  nodes  can  both  transmit  to  and  receive  from  all  other  nodes.  This 
mechanism  requires  each  node  to  maintain  the  total  number  of  all  connections  within 
each  group,  while  the  multicast  server  mechanism  requires  only  two  connections. 
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In  short,  there  is  no  ideal  solution  yet  within  ATM  for  multicast.  The  higher  layer 
protocols  for  ATM  multicast,  using  a  combination  of  multicast  server  and  overlaid  point- 
to-multipoint  connections,  are  currently  under  development  in  the  concept  of  “Multicast 
Address  Resolution  Server  (MARS)”  by  the  ATM  industry.  In  the  meantime,  we  will  be 
dependent  on  the  two  main  configurations  of  either  using  a  broadcast  and  unknown  server 
within  multiple  emulated  LANs  in  LAN  emulation  configuration  or  using  multiple  point- 
to-multipoint  PVC  connections  on  top  of  Classical  IP  over  ATM  point-to-point  Switched 
Virtual  Circuits  (SVC)  connections. 

6.2,1.  ATM  LAN  Emulation-Based  Multicast  Test 

A.  Objective: 

To  verify  an  ATM  switch’s  capability  of  multicasting  with  a  required  data  rate  from  a 
mission  computer  to  multiple  display  consoles.  The  multicast  is  based  on  UDP/IP 
protocol  and  is  used  for  common  data  broadcasting  to  all  consoles  within  a  multicast 
group  on  a  periodic  basis. 

B.  Approach: 

The  ATM  LANE  can  support  multiple  independent  Emulated  LAN  (ELAN)  networks. 
Membership  of  an  end  system  in  any  of  the  emulated  LANs  is  independent  of  the 
physical  location  of  the  end  system.  Since  LAN  emulation  connectivity  is  defined  at  the 
Medium  Access  Control  (MAC)  layer,  upper  layer  protocols  of  LAN  applications  remain 
unchanged  when  the  ATM  or  LAN-attached  devices  join  emulated  LANs.  With  multiple 
emulated  LANs  and  the  LANE’s  broadcasting  capability,  ATM  multicasting  was 
demonstrated.  The  ATM  LANE  operation  procedure  is  shown  in  Figure  6.2. 1-1. 

C.  Test  Items: 

•  Multiple  emulated  LANs  using  ATM  LANE. 

D.  Test  Procedure: 

a)  Connect  Cisco  ATM  switch  to  Catalyst-5000  LAN  Switch  with  an  OC-3c  link. 

b)  Configure  the  Cisco  Catalyst-5000  LAN  Switch  as  LEC,  LES,  BUS,  and  LECS. 

c)  Configure  multiple  LECs  on  the  ATM  interface. 

d)  Configure  a  LECS,  LES,  and  BUS  for  multiple  ELANs  on  the  ATM  interface. 

e)  Allow  the  clients  to  connect  to  the  LANE  services. 

f)  Verify  if  the  client  can  multicast  to  some  of  the  clients. 

E.  Expected  Results: 

The  multicast  configuration  with  multiple  ATM  emulated  LANs  was  properly  set  up  as 
shown  in  Figure  6.2. 1-2.  The  ATM  multicast  functionality  was  properly  verified. 
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ATM  LAN  Emulation  Operation  Procedure 


A.  Initialization  and  Configuration 

0.  Upon  power  up,  LEG  registers  its  own  ATM  address 

1.  LEC  requests  to  join  ELAN 

2.  LEGS  identifies  LES  and  provides  the  LES  identification  to  LEC 

B.  Joining  and  Registering  with  LES 

3.  LEC  registers  with  LES 

4.  LES  verifies  with  LEGS  that  LEC  is  allowed  to  join  the  ELAN 

5.  LES  allows  or  does  not  allow  the  LEC  to  join  the  ELAN 

C.  Finding  and  Joining  BUS 

6.  LEC  sends  LE-ARP  packets  to  LES  for  finding  the  BUS  ATM  address 

7.  LEC  sets  up  the  multicast-send  connection  to  BUS 

8.  BUS  sets  up  the  multicast-forward  connection  to  LEC 

D.  Data  Transfer 

9.  BUS  floods  a  data  packet  to  all  LECs  on  the  ELAN 

10.  LEC  resolves  an  ATM  address  of  the  unknown  destination  LEC 

11.  LEC  sends  BUS  LANE  flushing  message  and  then  starts  data  transfer 

Figure  6.2.1-1:  ATM  LAN  Emulation  Operation  Concept 
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ATM-based  AWACS  Network  Testbed 
with  LAN  Emulation  (LANE) 

(for  Integrated  Battlespace  Simulation  Demonstration) 
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Figure  6.2.1-2:  Multicast  Connguration  with  Multiple  ATM  Emulated  LANs 


6.2.2.  ATM  Classical  IP-Based  Multicast  Test 

A.  Objective: 

To  verify  an  ATM  switch’s  capability  of  multicasting  with  a  required  data  rate  from  a 
mission  computer  to  multiple  display  consoles.  The  multicast  is  based  on  UDP/IP 
protocol  and  is  used  for  common  data  broadcasting  to  all  consoles  within  a  multicast 
group  on  a  periodic  basis. 

B.  Approach: 

The  alternative  approach  to  ATM  multicasting  is  to  use  multiple  point-to-multipoint 
Permanent  Virtual  Circuits  (PVC)  connections  on  top  of  Classical  IP  over  ATM  point-to- 
point  Switched  Virtual  Circuits  (SVC)  connections.  In  this  configuration,  the  multiple 
point-to-multipoint  PVC  connections  link  all  nodes  in  the  multicast  group,  and  each  node 
is  given  a  unique  VPWCI  value.  The  operation  procedure  is  shown  in  Figure  6.2.2-1 . 

C.  Test  Items: 

•  Multiple  point-to-multipoint  Permanent  Virtual  Circuits  (PVC). 

D.  Test  Procedure: 

a)  Configure  the  Cisco  ATM  switch  in  a  single  point-to-multipoint  connection. 

b)  Select  the  ATM  interfaces  (ports)  to  be  configured. 

c)  Configure  a  VPW Cl  of  the  PVC  connection  at  the  root  port. 

d)  Configure  multiple  VPIsA^CIs  of  the  PVC  connections  at  the  leaf  port. 

e)  Configure  multiple  point-to-multipoint  connection. 

f)  Verify  the  PVC  between  ATM  switch  connections. 

g)  Verify  that  the  client  can  multicast  to  some  of  the  clients. 

E.  Expected  Results: 

The  multicast  configuration  vvdth  multiple  Permanent  Virtual  Circuits  (PVC)  on  top  of 
Classical  IP  over  ATM  Switched  Virtual  Circuits  (SVC)  connections  was  properly  set  up, 
as  shown  in  Figure  6.2.2-2.  The  ATM  multicast  functionality  was  properly  verified. 
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1.  The  sender  (LEC-1)  sends  an  ATMARP  request  to  ATMARP  Server  on 

the  logical  IP  subnet  to  find  an  ATM  address  of  the  receiver  (LEC-2). 

2.  ATMARP  returns  a  receiver's  ATM  address  to  the  sender. 

3.  LEC-1  starts  to  send  the  message  to  LEC-2. 

4.  When  LEC-2  receives  the  first  packet,  it  also  sends  an  ATMARP  request  to 

ATMARP  Server  to  find  the  location  of  the  sender  (LEC-1). 

5.  ATMARP  returns  a  sender's  ATM  address  to  the  receiver. 

6.  LEC-1  and  LEC-2  can  directly  communicate. 


Figure  6.2.2-1;  Classical  IP  over  ATM  Operation  Concept 
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ATM-based  AWACS  Network  Testbed 
with  Classical  IP  and  Multicast  PVC's 

(for  Integrated  Battlespace  Simulation  Demonstration) 
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Figure  6.2.2-2:  Multicast  Configuration  with  Classical  IP  and  PVCs 


6.3.  ATM/FDDI  Network  Benchmark  Test  with  AW  ACS  Platforms 

The  existing  Advanced  AWACS  network  architecture  is  based  on  FDDI;  the  proposed 
architecture  uses  ATM  over  OC-3c  (155  Mbps).  While  the  interim  and  the  final 
demonstrations  are  the  most  visible  tasks  of  this  program,  the  quantitative  ATM 
performance  measures  are  also  important.  Generally,  throughput  and  latency  are  the  two 
most  important  network  architecture  metrics.  Within  the  context  of  the  Advanced 
AWACS  network  architecture,  point-to-point  and  multicast  throughputs  are  of  particular 
interest. 

The  throughput  test  was  performed  for  three  distinct  network  implementations:  (1)  ATM 
with  classical  IP  (RFC  1577)  and  PVCs  for  multicast,  (2)  ATM  with  LANE,  and  (3) 
FDDI.  Each  of  these  three  network  implementations  was  tested  in  three  distinct 
configurations:  (1)  Point-to-point  TCP  duplex,  (2)  Point-to-multipoint  UDP  simplex,  and 
(c)  Simultaneous  TCP  duplex  and  UDP  simplex. 

6.3.1.  Network  Benchmark  Test  Tools 

Benchmarks  are  tests  commonly  used  to  predict  the  performance  of  an  unknown  system. 
The  popular  network  performance  benchmarks  can  be  achieved  by  using  public  domain 
software  tools.  Different  groups  of  test  tools  exist  -  from  simple  software  programs  to 
complex  network  analyzers  -  which  could  be  used  for  monitoring,  diagnosis,  and 
performance  measurement  of  a  system  or  subsystem.  Among  various  tools  available  for 
network  monitoring  and  performance  tests,  the  following  tools  were  chosen  especially  for 
ATM-based  networks:  Internet  Control  Message  Protocol  (ICMP)  ECHO_REQUEST 
and  ECHO_RESPONSE  (i.e.,  “PING”),  NTTCP,  NETPERF,  NETTEST,  and 
NETCONFIG. 

A.  PING  and  BING: 

The  PING  is  the  most  common  network  monitoring  tool  that  can  be  used  for  network 
testing,  measurement  and  management.  It  utilizes  the  ICMP’s  ECHO_REQUEST 
datagram  to  elicit  an  ECHO_RESPONSE  from  a  host  or  gateway.  The 
ECHO_REQUEST  datagram  has  an  IP  and  ICMP  header,  followed  by  an  8-byte 
timestamp,  and  then  an  arbitrary  number  of  “pad”  bytes  used  to  fill  out  the  packet.  To 
initiate  the  ECHO  service,  a  sender  host  sends  the  ICMP  data  unit  with  the  address  of  the 
destination  host  and  the  IP  address  filed.  The  host  can  be  its  name  or  its  IP  address. 

The  PING  continually  sends  one  datagram  per  second,  and  prints  one  line  of  output  for 
every  ECHO_RESPONSE  returned.  If  the  -c  count  option  is  given,  only  that  number  of 
requests  is  sent.  No  output  is  produced  if  there  is  no  response.  Round-trip  times  and 
packet  loss  statistics  are  computed.  If  duplicate  packets  are  received,  they  are  not 
included  in  the  packet  loss  calculation,  although  the  round  trip  time  of  these  packets  is 
used  in  calculating  the  minimum/average/maximum  round-trip  time  numbers.  When  the 
specified  number  of  packets  have  been  sent  (and  received)  or  if  the  program  is  terminated 
with  an  interrupt  (SIGINT),  a  brief  summary  is  displayed.  When  not  using  the  -f  (flood) 
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option,  the  first  interrupt,  usually  generated  by  control-C  or  DEL,  causes  PING  to  wait 
for  its  outstanding  requests  to  return.  It  will  wait  no  longer  than  the  longest  round  trip 
time  encountered  by  previous,  successful  pings.  The  second  interrupt  stops  PING 
immediately. 

The  PING  will  report  duplicate  and  damaged  packets.  Duplicate  packets  should  never 
occur,  and  seem  to  be  caused  by  inappropriate  link-level  retransmission.  Duplicates  may 
occur  in  many  situations  and  are  rarely  (if  ever)  a  good  sign,  although  the  presence  of  low 
levels  of  duplicates  may  not  always  be  cause  for  alarm.  Damaged  packets  are  obviously 
serious  cause  for  alarm  and  often  indicate  broken  hardware  somewhere  in  the  PING 
packet's  path  (in  the  network  or  in  the  hosts). 

There  are  modified  PING  tools  such  as  BING  (Bandwidth  PING).  The  BING  is  a  point- 
to-point  bandwidth  measurement  tool,  based  on  PING.  The  BING  determines  the  real 
throughput  on  a  link  by  measuring  ICMP  echo  requests  round-trip  times  for  different 
packet  sizes  for  each  end  of  the  link.  It  allows  a  host  A  to  remotely  measure  the 
throughput  between  remote  links  LI  and  L2,  two  extremities  of  a  point-to-point  link.  By 
measuring  the  round-trip  time  (rtt)  between  A  and  LI,  and  rtt  between  A  and  L2,  the  time 
between  LI  and  L2  can  be  deduced.  If  we  do  that  for  two  different  packet  sizes,  we  can 
compute  the  real  throughput  (as  opposed  to  available  or  average  throughput)  of  the  link. 

B.  NTTCP: 

NTTCP  is  a  benchmarking  tool  for  determining  TCP  and  UDP  performance  between  two 
systems.  NTTCP  times  the  transmission  and  reception  of  data  between  two  systems 
using  the  UDP  or  TCP  protocols  and  it  tests  the  bulk  transfers  with  variations  of  number 
of  buffers  and  sizes.  It  differs  from  common  "blast"  tests,  which  tend  to  measure  the 
remote  inetd  (internet  service  daemon)  as  much  as  the  network  performance,  and  which 
usually  do  not  allow  measurements  at  the  remote  end  of  a  UDP  transmission. 

For  testing,  the  transmitter  should  be  started  with  -t  and  -s  after  the  receiver  has  been 
started  with  -r  and  -s.  Tests  lasting  at  least  tens  of  seconds  should  be  used  to  obtain 
accurate  measurements.  Graphical  presentations  of  throughput  versus  buffer  size  for 
buffers  ranging  from  tens  of  bytes  to  several  “pages”  can  illuminate  bottlenecks. 
NTTCP  can  also  be  used  as  a  “network  pipe”  for  moving  directory  hierarchies  between 
systems  when  routing  problems  exist  or  when  the  use  of  other  mechanisms  is  undesirable. 

C.  NETPERF: 

Netperf  is  a  networking  benchmark  tool  developed  by  Hewlett-Packard  that  allows 
measurement  of  various  aspects  of  networking  performance.  The  current  version  is 
focusing  on  bulk  data  transfer  throughput  (bandwidth)  and  request-response  (latency) 
tests  for  TCP  and  UDP  using  the  Berkeley  Socket  interface.  This  is  widely  used  by  the 
ATM  industry  as  a  standard  benchmarking  tool.  There  are  optional  tests  available  to 
measure  the  performance  of  UNIX  Domain  Sockets,  FORE  ATM  API,  and  HP  HIPPI 
link  level  access. 
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The  most  common  test  is  to  measure  bulk  data  transfer  performance  (throughput).  This  is 
referred  to  as  TCP  stream  or  unidirectional  UDP  stream  performance.  The  TCP  stream 
performance  test  will  perform  a  10-second  test  between  the  local  host  and  the  remote 
host.  The  UDP  stream  performance  test  is  similar  to  a  TCP  stream  test.  One  difference  is 
that  the  transmit  size  can  not  be  larger  than  the  smaller  of  the  local  and  remote  socket 
buffer  sizes.  The  second  test  is  to  measure  request-response  or  transaction  performance. 
A  transaction  is  defined  as  the  exchange  of  a  single  request  and  a  single  response.  From  a 
transaction  rate,  one  can  infer  one  way  and  round-trip  average  latency. 
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6.3.2.  TCP  Performance  Test 


A.  Objective: 

To  measure  the  throughput  of  the  Point-to-Point  (P-P)  TCP  duplex  configuration  over 
each  network  implementation.  This  configuration  demonstrates  multiple  point-to-point 
TCP  connections  between  one  Mission  Computer  (MC)  and  four  Display  Consoles  (DC). 
Specifically,  there  are  no  multicast  communications  included  in  this  configuration. 

B.  Approach: 

The  test  uses  the  Netperf  and/or  NTTCP  configured  as  “server”  on  the  MC  and  as  “client” 
on  the  DCs.  The  parameters  are  DC  receive/transmit  buffer  size,  MC  transmit/receive 
buffer  size,  and  MC  TCP  transmit  message  size.  Multiple  TCP  connections  between  the 
MC  and  DCs  will  be  established,  and  corresponding  throughput  measured. 

C.  Test  Items: 

•  Throughput  at  MC/DCs. 

D.  Test  Procedure: 

a)  Use  Netperf  and/or  NTTCP  on  MC  (server)  and  DCs  (client). 

b)  Vary  the  transmit  buffer  sizes  on  the  MC  and  DCs. 

c)  Vary  the  receive  buffer  sizes  on  the  MC  and  DCs. 

d)  Vary  the  transmit  message  sizes  on  the  MC. 

e)  For  each  combination,  observe  and  record  throughput  at  the  MC  and  DCs. 

f)  For  receive/transmit  socket  buffer  sizes  of  1, 2, 4,  8, 16, 32,  64,  and  128K  bytes  on 
the  MC  and  DCs. 

g)  For  MC  transmit  message  sizes  of  1, 10, 25,  50,  100,  500K,  1,  5,  lOM  bytes. 

h)  Measure  the  throughput  with  P-P  TCP  cormections  for  each  DC. 

E.  Expected  Results: 

All  tests  were  performed  in  three  different  network  configurations:  FDDl,  ATM  LANE, 
ATM  Classical  IP  (CIP),  and  multicast  PVCs.  The  most  common  test  is  to  measure  bulk 
data  transfer  performemce  (throughput)  in  either  a  TCP  stream  or  a  unidirectional  UDP 
stream.  Figures  6. 3.2-1  through  6.3.2-10  summarize  the  TCP_STREAM  and 
TCP_REQUEST/RESPONSE  test  performance  in  three  different  configurations. 

Figures  6.3.2-1  to  6.3.2-4  show  the  TCP_STREAM  throughput  test  performance.  The 
maximum  throughputs  in  the  TCP_STREAM  test  of  FDDl,  ATM  LANE,  and  ATM  CIP 
were  96  Mbps,  108  Mbps,  and  118  Mbps,  respectively,  over  variable  message  size.  The 
throughput  increased  with  the  receive  and  transmit  socket  buffer  size,  but  it  is  relatively 
insensitive  to  the  message  size  when  it  is  bigger  than  the  Maximum  Transmission  Unit 
(MTU).  The  second  test  is  to  measure  a  transaction  rate  performance.  A  transaction  is 
defined  as  the  exchange  of  a  single  Request/Response  (RR).  Figures  6.3. 2-5  to  6.3. 2-8 
show  TCP_RR  test  results.  The  round-trip  delay  can  be  estimated  from  a  transaction  rate; 
with  a  1  KByte  message,  0.63  ms  (FDDl),  0.58  ms  (ATM  LANE),  and  0.60  ms  (ATM 
CIP),  all  for  TCP  traffic. 
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Figure  6.3.2-l(a):  FDDI  TCP  Performance 
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Figure  6.3.2-l(b):  ATM  LANE  TCP  Performance 
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Figure  6.3.2-l(c):  ATM  CIP  TCP  Performance 
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FDDI  NETPERF  TCP_STREAM  TEST  (USA->UK) 
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Figure  6.3.2-2(a):  FDDI  TCP  Performance 
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Figure  6.3.2-2(b):  ATM  LANE  TCP  Performance 


ATM_CIP  NETPERF  TCP_STREAM  TEST  (USA->UK) 


16kB  buffer 
PI  32kB  buffer  ‘ 
^  64kB  buffer 
m  128kB  buffer 


Figure  6.3.2-2(c):  ATM  CIP  TCP  Performance 
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figure  6.3.2-3(a):  ATM  LANE  TCP  Performance  (by  NTTCP) 
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Figure  6.3.2-3(b):  ATM  CIP  TCP  Performance  (by  NTTCP) 
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Figure  6.3.2-4(a):  FDDI  TCP  Performance 
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Figure  6.3.2-4(b):  ATM  LANE  TCP  Performance 
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Figure  6.3.2-4(c):  ATM  CIP  TCP  Performance 
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Figure  6.3.2-5(a):  FDDI  TCP  Performance 
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Figure  6.3.2-5(b):  ATM  LANE  TCP  Performance 
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Figure  6.3.2-5(c):  ATM  CIP  TCP  Performance 
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Figure  6.3.2-6(a):  FDDI  TCP  Performance 
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Figure  6.3.2-6(b):  ATM  LANE  TCP  Performance 


ATM_CIP  NETPERF  TCP_RR  TEST  (USA->UK) 


RR_Message  Size  (kB) 


^  ifikB  buffer 
32kB  buffer 

_ 64kB  buffer 

__*_128kB  buffer; 


Figure  6.3.2-6(c):  ATM  CIP  TCP  Performance 
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Figure  6.3.2-7(a):  FDDI  TCP  Performance 
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Figure  6.3.2-7(b):  ATM  LANE  TCP  Performance 
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Figure  6.3.2-7(c):  ATM  CIP  TCP  Performance 
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RR_Transactions  (per  sec' 


FDDI  NETPERF  TCP_RR  TEST  (USA->UK) 
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Figure  6.3.2-8(a):  FDDI  TCP  Performance 


ATM_LANE  NETPERF  TCP_RR  TEST  (USA->UK) 
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Figure  6.3.2-8(b):  ATM  LANE  TCP  Performance 


ATM_CIP  NETPERF  TCP_RR  TEST  {USA->UK) 
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Figure  6.3.2-8(c);  ATM  CIP  TCP  Performance 
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6.3.3.  UDP  Performance  Test 


A.  Objective: 

To  measure  the  throughput  of  the  Point-to-Point  (P-P)  UDP  simplex  and  Point-to- 
Multipoint  (P-M)  UDP  simplex  configuration  over  eaeh  network  implementation.  The 
point-to-multipoint  configuration  demonstrates  an  UDP  communication  stream  from  one 
Mission  Computer  (MC)  to  four  Display  Consoles  (DC). 

B.  Approach: 

With  the  same  approach  as  section  6.3.2,  the  parameters  will  be  DC  receive  buffer  size, 
MC  transmit  buffer  size,  and  MC  UDP  transmit  message  size.  A  single  UDP  distribution 
from  the  MC  to  the  DCs  will  be  established  and  corresponding  throughput  measured. 

C:  Test  Items: 

•  Throughput  at  MC/DCs. 

D.  Test  Procedure: 

a)  Use  Netperf  and/or  NTTCP  on  MC  (server)  and  DCs  (client). 

b)  Vary  the  transmit  buffer  sizes  on  the  MC  and  DCs. 

c)  Vary  the  receive  buffer  sizes  on  the  MC  and  DCs. 

d)  Vary  the  transmit  message  sizes  on  the  MC. 

e)  For  each  combination,  observe  and  record  throughput  at  the  MC  and  DCs. 

f)  For  receive/transmit  socket  buffer  sizes  of  1, 2, 4,  8, 16,  32,  64,  and  128K  bytes  on 
the  MC  and  DCs. 

g)  For  MC  transmit  message  sizes  of  1,  10, 25,  50,  100,  500K,  1,  5,  lOM  bytes. 

h)  Measure  the  throughput  with  P-P  UDP  eind  P-M  UDP  connections  for  each  DC. 

E.  Expected  Results: 

All  tests  were  performed  in  three  different  network  configurations:  FDDI,  ATM  LANE, 
ATM  Classical  IP  (CIP)  and  multicast  PVCs.  The  throughput  of  the  Point-to-Point  (P-P) 
UDP  simplex  was  measured.  The  NTTCP  and  NETPERf  do  not  allow  for  the  Point-to- 
Multipoint  (P-M)  UDP  simplex  test.  For  UDP_STREAM  test,  FDDI  can  best  handle 
UDP  traffic  irrespective  of  socket  buffer  size  and  without  considering  delay  time 
variation.  ATM  LANE  and  CIP  may  require  a  proper  delay  time  between  UDP  traffics. 
TCP  and  UDP  round-trip  delay  time  was  slightly  faster  in  ATM  (LANE  or  CIP)  than 
delay  time  in  FDDI,  but  all  were  within  the  AWACS  requirement  of  less  than  10  ms,  as 
long  as  the  message  size  was  less  than  10  kByte.  Figures  6.3.3-1  to  6.3.3-6  summarize  the 
UDP_STREAM  and  UDP  REQUEST/RESPONSE  performance  in  three  configurations. 

The  UDP  stream  performance  test  is  similar  to  a  TCP  stream  test.  The  one  difference  is 
that  the  transmit  size  can  not  be  larger  than  the  smaller  of  the  local  and  remote  socket 
buffer  size.  The  UDP_STREAM  test  in  Figure  6.3.3.-l(a),  (b),  (c)  showed  that  FDDI 
outperformed  ATM,  irrespective  of  socket  buffer  size.  Even  with  the  transmit  size 
constraint,  it  still  may  need  to  control  the  interval  between  packets  to  keep 
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UDP_STREAM  from  running  away  with  all  the  resources  of  the  ATM  network.  Note  that 
the  delay  between  sending  packets  was  not  counted  in  this  UDP  throughput  test;  this  can 
be  a  subject  for  further  study.  The  UDP  transaction  rate  performance  is  shown  in  Figures 
6. 3.3-4  to  6. 3. 3-6.  Similarly,  the  average  round-trip  delay  can  be  estimated  from  a 
transaction  rate:  0.61  ms  for  UDP  in  all  cases  with  a  1  KByte  message. 


FDDI  NETPERF  UDP_STREAM  TEST  (USA->UK) 


_4 _ 16kB  bufer 

_32kB  buffer 
fi4kR  buffer 
_<^128kB  buffer 


Figure  6.3.3-l(a):  FDDI  UDP  Performance 


ATM_LANE  NETPERF  UDP_STREAM  TEST  (USA->UK) 


Figure  6.3.3-l(b):  ATM  LANE  UDP  Performance 
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Throughput  (Mbps)  |  |  Throughput  (Mbps)  Throughput  (Mbps) 


ATM_CIP  NETPERF  UDP_STREAMTEST  (USA->UK) 


i  _^_16kB  buffer 
i  — ~  32kB  buffer 
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Figure  6.3.3-l(c):  ATM  CIP  UDP  Performance 


ATM_LANE  NTTCP  UDP_STREAM  TEST  (USA->UK) 
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figure  6.3,3-2(a):  ATM  LANE  UDP  Performance  (by  NTTCP) 


ATM_CIP  NTTCP  UDP_STREA1VI  TEST  (USA->UK) 
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Figure  6.3.3-2(b):  ATM  CIP  UDP  Performance  (by  NTTCP) 
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FDDI  NETPERF  UDP_STREAIVITEST  (USA->UK) 
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^ _ lOOkB  message 


Figure  6.3.3-3(a):  FDDI  UDP  Performance 


ATM_LANE  NETPERF  UDP_STREAM  TEST  (USA->UK) 
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Figure  6.3.3-3(b):  ATM  LANE  UDP  Performance 


ATM_CIP  NETPERF  UDP_STREAM  TEST  (USA->UK) 
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Figure  6.3,3-3(c):  ATM  CIP  UDP  Performance 
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RR_Transactions  (persec)  |  RR_Transactions  (persec)  RR_Transactions  (persec) 


FDDI  NETPERF  UDP_RR  TEST  (USA->UK) 


_ 1 B  RR_message 
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^ _ 100B  RR_message 
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Figure  6.3.3-4(a):  FDDI  UDP  Performance 


ATM_LANE  NETPERF  UDP_RRTEST  (USA->UK) 


»  1B  RR_message 
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Figure  6.3.3-4(b):  ATM  LANE  UDP  Performance 


ATM_CIP  NETPERF  UDP_RRTEST  (USA.>UK) 
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Figure  6.3.3-4(c):  ATM  CIP  UDP  Performance 


66 


FDDI  NETPERF  UDP_RR  TEST  (USA->UK) 
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Figure  6.3.3-5(a):  FDDI  UDP  Performance 


ATM_LANE  NETPERF  UDP_RR  TEST  (USA->UK) 
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Figure  6.3.3-5(b):  ATM  LANE  UDP  Performance 
ATM_CIP  NETPERF  UDP_RR  TEST  (USA->UK) 
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Figure  6.3.3-5(c):  ATM  CIP  UDP  Performance 
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RR_Transactions  (persGc)  i  |  RR_Transactions  (per  sec) 


FDDI  NETPERF  UDP_RR  TEST  (USA->UK) 


RR_Message  Size  (kB) 


Figure  6.3.3-6(a):  FDDI  UDP  Performance 


ATM_LANE  NETPERF  UDP_RRTEST  (USA->UK) 


RR_Message  Size  (kB) 


Figure  6.3.3-6(b):  ATM  LANE  UDP  Performance 
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ATM_CIP  NETPERF  UDP_RR  TEST  (USA->UK) 
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Figure  6.3.3-6(c):  ATM  CIP  UDP  Performance 
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6.3.4.  Simultaneous  TCP  and  UDP  Performance  Test 

A.  Objective: 

This  configuration  is  a  superposition  of  the  previous  two  configurations  simultaneously 
demonstrating  (1)  multiple  point-to-point  TCP  connections  between  a  Mission  Computer 
(MC)  and  four  Display  Consoles  (DC),  and  (2)  a  single  point-to-point  and/or  point-to- 
multipoint  UDP  communication  stream  from  one  MC  to  four  DCs.  The  objective  of  this 
test  is  first  to  measure  the  throughput  of  multiple  point-to-point  TCP  connections  over 
each  network  implementation,  in  the  presence  of  configuration  (2),  and  second  to 
measure  the  throughput  of  a  single  point-to-point  and/or  point-to-multipoint  UDP 
distribution  over  each  network  implementation,  in  the  presence  of  configuration  (1). 

B.  Approach: 

With  the  same  approach  as  sections  6.3.2  and  6.3.3,  the  parameters  were  DC 
receive/transmit  buffer  size,  MC  transmit/receive  buffer  size,  MC  TCP  transmit  message 
size,  and  MC  UDP  transmit  message  size.  Multiple  TCP  connections  between  the  MC 
and  DCs  were  established  simultaneously  with  a  single  UDP  distribution  from  the  MC  to 
the  DCs,  and  corresponding  throughputs  were  measured. 

C.  Test  Items: 

•  Throughput  at  MC/DCs. 

D.  Test  Procedure: 

a)  Use  Netperf  and/or  NTTCP  on  MC  (server)  and  DCs  (client). 

b)  Vary  the  transmit  buffer  sizes  on  the  MC  and  DCs. 

c)  Vary  the  receive  buffer  sizes  on  the  MC  and  DCs. 

d)  Vary  the  transmit  message  sizes  on  the  MC. 

e)  For  each  combination,  observe  and  record  throughput  at  the  MC  and  DCs. 

f)  For  receive/transmit  socket  buffer  sizes  of  1, 2, 4,  8,  16,  32,  64,  and  128K  bytes  on 
the  MC  and  DCs. 

g)  For  MC  transmit  message  sizes  of  1,  10, 25,  50,  100,  500K,  1,  5,  lOM  bytes. 

h)  Measure  the  throughput  -with  simultaneous  P-P  TCP  and  P-P  and/or  P-M  UDP 
conneetions  for  each  DC. 

E.  Expected  Results: 

The  NTTCP  and  NETPERF  do  not  allow  for  the  simultaneous  TCP  and  UDP  test.  One 
potential  way  was  testing  TCP  performance  while  running  UDP  traffic  on  backgroimd, 
and  vice  versa.  Figure  6. 3. 4- 1(a),  (b)  show  test  examples  of  the  FDDI  network  in  the 
simultaneous  TCP  and  UDP  stream.  Note  that  one  type  of  traffic  was  handled  first  and 
the  other  traffic  waited  for  its  turn,  so  this  might  not  be  a  true  simultaneous  test  of  TCP 
and  UDP.  Therefore,  the  truly  simultaneous  test  of  TCP  and  UDP  was  performed  with  an 
AWACS  application  program  in  Section  6.4. 

Since  a  real  AWACS  application  requires  TCP  unicast  and/or  UDP  multicast,  besides  the 
separate  TCP  and  UDP  unicast  tests,  it  would  be  interesting  to  test  the  performance  of  (1) 
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TCP  or  UDP  multicast,  (2)  simultaneous  TCP  unicast  and  UDP  unicast,  and  (3) 
simultaneous  TCP  unicast  and  UDP  multicast.  However,  it  should  be  noted  that  the  UDP 
multicast  and  the  simultaneous  TCP  and  UDP  multicast  tests  are  not  easily  implemented 
with  network  benchmark  tools.  They  are  tested  only  by  running  actual  AW  ACS 
application  programs  as  described  in  the  next  section.  The  one  way  for  us  to  closely 
simulate  the  scenarios  above  is  by  running  multiple  copies  of  netperf  at  the  same  time. 
Figures  6. 3. 4-1  and  6.3. 4-2  show  the  example  of  TCP  multicast  test  by  sending  a 
TCP  STREAM  test  message  to  all  destinations  (a.k.a,  TCP-All)  at  the  same  time.  The 
test  script  with  multiple  copies  of  netperf  commands  allows  TCP  and  UDP  streams  to  run 
at  almost  the  same  time.  It  is  worthwhile  to  mention  that  these  tests  need  more  study  to 
establish  their  validity  of  test  method  and  results  (Figures  6.3.4-1  and  6.3.4-2). 


FDDI  NETPERF  TCP_UDP_STREAMTEST  (USA->UK) 


. V'tr7p'64kB' buffer 

,,  .g  TCP  128kB  buffer 
^  UDP  64kB  buffer 
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Figure  6.3.4-l(a):  FDDI  TCP  and  UDP  Performance 


FDDI  NETPERF  TCP_UDP_STREAM  TEST  (USA->UK) 
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Figure  6.3.4-l(b):  FDDI  TCP  and  UDP  Performance 
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Throughput  (Mbps)  Throughput  (Mbps) 


ATM_LANE  NETPERF  TCP_UDP_STREAM  TEST  (USA->UK) 


TCP  64kB  buffer 
TCP  128kB  buffer 
^  UDP  64kB  buffer 
_*__UDP  128kB  buffer 


Figure  6.3.4-l(c):  ATM  LANE  TCP  and  UDP  Performance 


ATM_CIP  NETPERF  TCP_UDP_STREAMTEST  (USA->UK) 
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Figure  6.3.4-l(d):  ATM  CIP  TCP  and  UDP  Performance 
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Throughput  (Mbps)  Throughput  (Mbps)  Throughput  (Mbps) 


FDDI  NETPERF  TCP_STREAM  TEST  (USA->ALL) 
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Figure  6.3.4-2(a):  FDDI  TCP  Performance 


ATM_LANE  NETPERF  TCP_STREAM  TEST  (USA->ALL) 
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Figure  6.3.4-2(b):  ATM  LANE  TCP  Performance 


ATM_CIP  NETPERF  TCP_STREAM  TEST  {USA->ALL) 
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Figure  6.3.4-2(c):  ATM  CIP  TCP  Performance 
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FDDI  NETPERF  TCP_STREAM  TEST  (USA->ALL) 
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Figure  6.3.4-3(a):  FDDI  TCP  Performance 


ATM_LANE  NETPERF  TCP_STREAM  TEST  (USA->ALL) 
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Figure  6.3.4-3(b):  ATM  LANE  TCP  Performance 


ATM_CIP  NETPERF  TCP_STREAM  TEST  (USA->ALL) 
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Figure  6.3.4-3(c):  ATM  CIP  TCP  Performance 
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6.4.  ATM/FDDI  Application  Benchmark  Test  with  AWACS  Programs 

The  AWACS  system  loading  can  involve  a  large  number  of  simulated  targets,  sensor 
returns  (e.g.,  radar  returns,  IFF  returns),  and  active  tracks.  The  proper  number  of  tracks 
and  simulated  targets  allowed  by  the  system  may  be  generated.  The  simulated  targets  are 
used  to  perform  an  internal  simulation  of  targets  within  the  system.  Sensor  returns  are 
then  generated  internally  by  the  Mission  Computer  (MC)  program  applications  and  they 
are  used  to  generate  tracks.  Once  the  number  of  simulated  targets  have  been  generated, 
automatic  track  initiation  will  be  started  and  tracks  will  be  generated  off  the  simulated 
sensor  returns.  This  information  is  continuously  transmitted  to  the  Display  Console  (DC) 
program  and  it  can  be  displayed  as  requested. 

6.4.1.  TCP  Performance  Test 

A.  Objective: 

To  observe  the  qualitative  TCP  unicast  performance  of  representative  compilations  of  the 
Advanced  AWACS  application  software  running  over  each  applicable  network 
implementation:  ATM  Permanent  Virtual  Circuits  (PVC),  ATM  LANE,  and  FDDI 
networks. 

B.  Approach: 

For  each  network  implementation  (ATM  PVC,  ATM  LANE,  and  FDDI),  representative 
compilations  of  the  AWACS  application  will  be  executed  on  the  target  platforms 
consisting  of  one  Mission  Computer  (MC)  and  four  Display  Consoles  (DC).  A  series  of 
executables  will  be  compiled,  each  with  the  capacity  to  handle  a  progressively  larger 
number  of  targets  (1000,  2000,  3000).  This  approach  will  exercise  the  network 
sufficiently  to  examine  the  effects  of  each  network  implementation  on  the  actual 
performance  of  the  system.  The  intent  of  this  approach  will  be  to  determine  the  loading 
impact  at  which  network  functionality  is  degraded  in  an  observable  manner. 

C.  Test  Items: 

•  Point-to-point  TCP  performance  as  a  function  of  maximum  number  of  targets: 
Performance  of  the  actual  TCP  connections  between  the  MC  and  the  DCs  will 
be  evaluated  as  satisfactory  or  not-satisfactory  based  on  observing  the  tabular 
display  indicator  Time.  This  indicator  is  updated  at  a  1-  to  2-  second  rate  and 
represents  software  watchdog  timer  activity  operation  to  a  100-ms  time 
resolution.  Aberrations  in  the  displayed  time  values  are  indicative  of  TCP 
connection  problems. 

•  General  network  performance  as  a  function  of  maximum  number  of  targets: 
Certain  communication  network  errors  associated  with  software-detectable 
aberrations  will  cause  the  activation  of  a  user-alert  -  indicative  of  the  network 
communications  problem. 
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D.  Test  Procedure: 

Beginning  with  the  executable  compiled  for  the  smallest  number  of  targets  and 
proceeding  through  progressively  larger  such  executables,  the  representative  AWACS 
application  will  be  executed  with  appropriately  sized  scenarios.  The  application  will  be 
run  on  each  network  implementation  and  all  network  observables  indicated  above  will  be 
noted.  Other  means  of  automating  the  observation  process  may  also  be  employed. 

OSA  AWACS  application  software  was  built  for  benchmark  testing.  This  test  software 
allows  for  varying  the  number  of  simulated  targets  (1,000,  2,000,  3,000)  and  socket 
buffer  size  (up  to  1.5  MB).  The  network  benchmark  software  tools  (e.g.,  nttcp,  netperf) 
were  installed  into  all  platforms  (i.e..  Alpha,  Sparc,  and  Onyx  workstations)  of 
demonstration  systems.  With  these  network  test  software  and  application  test  software, 
we  first  performed  the  FDDI  benchmarking,  followed  by  ATM  testing.  We  reconfigured 
all  system  components  (AWACS,  UAV,  and  fighter)  by  connecting  to  the  FDDI  and 
ATM  networks  for  the  network  benchmark  test. 

The  application  performance  test  was  performed  with  the  Advanced  AWACS  Mission 
Computer  Program  (MCP)  and  Display  Console  Program  (DCP).  The  C"*!  platform 
system  loading  can  be  a  large  number  of  simulated  targets,  sensor  returns  (radar  or  IFF 
returns),  and  active  tracks.  The  maximum  number  of  over  1,000  tracks  and  simulated 
targets  were  generated.  Sensor  returns  were  then  generated  internally  by  the  AWACS 
mission  computer.  Once  the  number  of  simulated  targets  have  been  generated,  the 
automatic  track  initiation  will  be  started  and  the  tracks  generated  off  the  simulated  sensor 
returns.  This  information  is  continuously  transmitted  to  the  AWACS  Display  Consoles  to 
observe  the  simultaneous  TCP  unicast  and  UDP  multicast  performance  of  the  Advanced 
AWACS  application  running  over  each  network. 

E.  Expected  Results: 

Due  to  the  worst-case  scenario  design  of  the  Advanced  AWACS  system,  whereby  a  large 
portion  of  the  entire  database  is  continuously  updated,  our  observations  are  expected  to  be 
consistent  with  normal  operation  up  to  a  critical  network  loading  point,  beyond  which 
one  or  more  of  the  aberrations  listed  above  are  expected  to  occur,  manifested  in  a  manner 
consistent  with  the  observable  as  stated  above. 

Figures  6.4. 1-1,  -2,  -3  show  a  summary  of  the  Advanced  AWACS  application  test  with 
various  track  simulations  that  require  TCP  unicast  transmission  over  each  of  three 
different  network  configurations.  The  AWACS  application  program  was  modified  for 
this  test  so  that  the  socket  buffer  size  could  be  changed  at  run  time.  Test  results  showed 
that  all  networks  had  various  problems  associated  with  a  mission  computer  program 
and/or  database  transmit  problems  below  a  buffer  size  of  32kB.  The  MCP  problems 
include  the  occasional  disconnect/reconnect,  shutdown,  or  radar  returns  disappear  of 
simulated  target  data.  The  database  transmit  problems  involve  various  databases  that-do 
not  get  transmitted,  i.e.,  either  no  target,  point  objects,  or  no  tracks  get  updated.  Above 
64kB,  the  FDDI  and  ATM  CIP  showed  normal  operation,  while  ATM  LANE  also 
showed  mostly  normal  with  an  occasional  database  trtinsmit  problem. 
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The  files  <osa_app_test.txt>  contain  observations  related  to  running  a  modified  OSA 
application  test  build  over  the  FDDI,  ATM  LANE,  or  ATM  CIP/PVC  network. 

NOTE:  The  OSA  application  is  modified  for  this  test  so  that  the  socket  buffer  size  can  be 
changed  at  run  time.  The  OSA  application  has  40  socket  buffers.  In  the  OSA  application, 
most  socket  buffers  are  set  to  a  default  size  of  32*  1 024,  while  a  few  sockets  handling 
larger  amounts  of  data  are  set  to  128*1024,  and  the  sockets  handling  the  database  transfer 
are  set  to  a  function  of  the  database  size  not  exceeding  1400*1024.  However,  in  this 
modified  OSA  application  test  build,  all  sockets  are  set  to  a  single  value  of  buffer  size 
specified  in  the  configuration  file  <./DATA/CONFIG_DATA/network_test.cfg>. 

CLOCK:  The  number  shows  a  maximum  clock  update  time  (on  the  display  console  tab) 
that  was  observed  in  seconds.  Clock  updates  to  the  tab  do  not  necessarily  correspond  to 
actual  time. 

CRASH:  At  least  one  of  the  Display  Control  Programs  (DCP)  is  crashed  or  permanently 
disconnected  from  the  Mission  Computer  Program  (MCP)  while  running  the  OSA 
application  test. 

DBASE  XMIT:  The  various  databases  do  not  get  transmited;  no  target,  point  objects,  or 
no  tracks  get  updated. 

DISCONNECT:  The  MCP  occasionally  disconnects  and  reconnects. 

DISAPPEAR:  The  target  data  simulated  radar  returns  disappear. 

HIGHLIGHT:  The  Programmable  Entry  Panel  (PEP)  keys  do  not  highlight  properly. 

NORMAL:  The  modified  OSA  application  test  build  operates  normally. 

PANIC:  The  consoles  running  DCPs  enter  a  panic  mode  and  are  automatically  rebooted. 
One  of  the  following  error  messages  is  displayed:  (1)  Panic  (CPU  0):  kernel  memory 
fault;  or  (2)  Panic  (CPU  0):  freeing  free  mbuf 

SHUTDOWN:  The  SHUTDOWN  PEP  key  takes  the  MCP  down,  but  not  the  DCPs. 
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Figure  6.4.1-1:  AW  ACS  Application  TCP  Unicast  Test  over  FDDI 
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Figure  6.4.1-2:  AWACS  Application  TCP  Unicast  Test  over  ATM  LANE 
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Figure  6.4.1-3:  AW  ACS  Application  TCP  Unicast  Test  over  ATM  CIP* 
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6.4.2.  Simultaneous  TCP  and  UDP  Performance  Test 


A.  Objective: 

To  observe  qualitatively  the  simultaneous  TCP  and  UDP  performance  of  representative 
compilations  of  the  Advanced  AWACS  application  sofhvare  running  over  each 
applicable  network  implementation:  ATM  Permanent  Virtual  Circuits  (PVC),  ATM  LAN 
Emulation  (LANE),  and  FDDI  networks. 

B.  Approach: 

For  each  network  implementation  (ATM  PVC,  ATM  LANE,  and  FDDI),  representative 
compilations  of  the  AWACS  application  will  be  executed  on  the  target  platforms 
consisting  of  one  Mission  Computer  (MC)  and  four  Display  Consoles  (DC).  A  series  of 
executables  will  be  compiled,  each  with  the  capacity  to  handle  a  progressively  larger 
number  of  targets  (1000,  2000,  3000).  This  approach  will  exercise  the  network 
sufficiently  to  examine  the  effects  of  each  network  implementation  on  the  actual 
performance  of  the  system.  The  intent  of  this  approach  will  be  to  determine  the  loading 
at  which  network  functionality  is  degraded  in  an  observable  manner. 

C.  Test  Items: 

•  Simultaneous  TCP  and  UDP  performance  as  a  function  of  maximum  number  of 
targets:  Performance  of  the  actual  UDP  multicast  distribution  from  the  MC  to 
the  DCs  will  be  evaluated  as  satisfactory  or  not-satisfactory  based  on  observing 
the  expected  movement  of  the  target  on  the  display. 

•  General  network  performance  as  a  function  of  maximum  number  of  targets: 
Certain  communication  network  errors  associated  with  software-detectable 
aberrations  will  cause  the  activation  of  a  user-alert  -  indicative  of  the  network 
communications  problem. 

D.  Test  Procedure: 

The  application  will  be  run  on  each  network  implementation  and  all  network  observables 
indicated  above  will  be  noted.  Other  means  of  automating  the  observation  process  may 
also  be  employed. 

E.  Expected  Results: 

Figure  6.4.2-1,  -2,  -3  show  a  summary  of  the  Advanced  AWACS  application  test  with  a 
3,000-track-simulation  that  requires  transmission  of  simultaneous  TCP  unicast  and  UDP 
multicast  over  each  of  three  different  network  configurations.  All  networks  had  various 
problems  associated  with  a  mission  computer  program  and/or  database  transmit  problems 
below  a  buffer  size  of  32kB.  The  MCP  problems  include  the  occasional 
disconnect/reconnect,  shutdovm,  or  radar  returns  disappear  of  simulated  target  data. 
Above  64kB,  the  FDDI  and  ATM  CIP  showed  normal  operation,  while  ATM  LANE  also 
showed  mostly  normal  with  an  occasional  panic  problem;  the  display  consoles  running 
AWACS  programs  occasionally  entered  a  panic  mode  and  automatically  rebooted. 
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Figure  6.4.2-1:  AW  ACS  Application  TCP  and  UDP  Test  over  FDDI 
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Figure  6.4.2-3:  AWACS  Application  TCP  and  UDP  Test  over  ATM  CIP* 
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7. 


ATM-BASED  AWACS  SYSTEM  DEMONSTRATION  (TASK  4) 


The  objective  of  the  interim  demonstration  is  to  demonstrate  the  Advanced  AWACS 
subsystem  configured  with  an  ATM  backbone.  In  this  task  our  intent  is  to  demonstrate 
the  same  functionality  based  on  ATM-based  networks  as  is  available  in  the  current 
Advanced  AWACS  architecture  based  on  Ethernet  and  FDDI  networks.  This  interim 
demonstration  involves  a  simulated  AWACS.  The  demonstration  uses  actual  flight 
software  with  internal  simulations  in  such  a  manner  that  the  designed-to  limits  of  the 
system  can  be  stressed.  Over  1,000  targets  will  be  simulated  which,  in  turn,  produce 
thousands  of  sensor  returns  from  the  simulated  targets  (e.g.,  radar,  IFF,  ESM)  and  over 
1,000  system  tracks  -  all  of  which  are  routed  to  all  the  consoles  for  display.  This 
demonstration  will  verify  that  ATM  is  capable  of  handling  the  operational  traffic. 

Using  the  surveillance  officer  and  weapons  director,  the  advanced  AWACS 
demonstration  scenario  includes  the  capabilities  of  various  displays,  targets/tracks  and 
battlespace  management,  and  Air  Tasking  Order  (ATO)  processing  and  data  display. 

1 .  ATM  Network  Demonstration. 

a)  Describe  ATM  network  configuration  (ATM  switch  connection). 

1)  LAN  emulation  configuration. 

2)  Classical  IP  configuration. 

3)  Multicast  PVC  configuration. 

b)  Demonstrate  ATM  network  configuration  (ping,  nttcp  or  netperf). 

1 )  LAN  emulation  configuration. 

2)  Classical  IP  configuration. 

3)  LANE  multicast  and  PVC  multicast  in  the  nttcp  UDP  chatter  mode. 

2.  Advanced  AWACS  Demonstration. 

a)  Surveillance  officer. 

1)  Display  a  new  SAM  site. 

2)  Set  the  ESM  line  of  bearing  for  the  new  SAM. 

3)  Look  at  a  TACELINT  MESSAGE. 

4)  Identify  the  new  SAM  site  as  SA-IO. 

5)  Predict  best  intercept. 

6)  Select  the  fighter  to  use  against  the  SA-10. 

b)  Weapons  Director. 

1)  Clear  the  predict  lines. 

2)  Commit  the  selected  fighter  to  the  SA-10. 

3)  Check  range/bearing  of  fighters  to  SAM  sites. 

4)  Within  weapon  range,  drop  range/bearing  lines,  and  delete  SAM  sites  from 
screen. 

5)  Commit  CAP  fighter  to  one  hostile  fighter. 

6)  Commit  selected  fighter  to  the  other  hostile  fighter. 

7)  Show  approaches. 
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3.  Interactive  Future  AW  ACS  Demonstration. 

a)  Displays  demonstration. 

1)  Situation  displays:  sensor  data,  area  definition  and  control. 

2)  Tabular  displays. 

3)  Points  displays. 

4)  Background  maps  displays. 

5)  Missile  and  weapon  sites  displays. 

6)  Latitude/Longitude  grid  displays. 

7)  Range  grid  displays. 

8)  AWACS  Line-Of-Sight  (LOS)  displays. 

9)  Range  bearing  and  tactical  range  bearing  lines. 

10)  Amplification  data  hook  (AMP  hook)  displays. 

b)  Targets  and  tracks  demonstration. 

1)  Radar  operation:  pulse  Doppler  vs.  beyond  the  horizon. 

2)  Active  track  initiation  and  monitoring. 

3)  Track  management. 

4)  Target  simulation. 

5)  Target  motion,  attributes,  and  interaction. 

6)  Aircraft  navigation. 

C)  Battlespace  management  demonstration. 

1)  Identification  Friend  or  Foe  (IFF)  /  radar  -  sectors  and  subsectors. 

2)  Electronic  Support  Measure  (ESM)  simulation  and  control. 

3)  Weapons  control. 

4)  Flight  plan  monitoring. 

5)  Air  Tasking  Order  (ATO)  processing  and  data  display. 

4.  Maximum  Targets  Demonstration  of  over  1,000. 
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8.  INTEGRATED  BATTLES? ACE  SIMULATION  (TASK  5) 

The  objectives  of  this  task  were  to  integrate  all  subsystems  into  the  final  demonstration 
configuration,  define  a  realistic  demonstration  scenario  for  C  I  specific  applications,  and 
demonstrate  the  “sensor-C4I-shooter”  sequence  in  an  integrated  battlespace  simulation 
environment.  The  final  demonstration  system  consisted  of  an  Advanced  AW  ACS  station 
(an  OSA  mission  computer  and  four  display  consoles),  a  simulated  UAV  ground  station 
(DEMPC  mission  planner  and  image  analyzer),  a  remote  advanced  fighter  station  (display 
generator  and  cockpit  display),  and  a  remote  computer  image  generator  station.  They 
were  located  at  the  Integrated  Technology  Development  Laboratory  (ITDL).  A  diagram 
of  the  final  demonstration  is  shown  in  Figure  4.3-2. 

The  Integrated  Battlespace  Simulation  (IBS)  environment  at  the  ITDL  will  provide 
simulated  participants  such  as  shooter,  UAV,  C''I  platform,  or  enemy  threats,  etc.,  and 
their  connectivity  for  interaction  between  participants  to  specifically  demonstrate  and 
analyze  intercommunications  and  data  management  with  operators  in  the  loop.  The 
modular  architecture  of  the  environment  will  make  it  capable  of  supporting  multiple 
players  in  joint  warfare  scenarios. 

The  entire  off-board-sensor-to-shooter  sequence  will  be  modeled  in  the  simulated 
battlespace  environment  that  is  designed  to  exercise  the  timeliness  of  receiving  tactical 
information,  including  the  response  time  of  the  operators.  Each  simulation  node  resides 
in  separate  laboratories  that  communicate  over  fiber  cables.  The  sequence  consists  of 
video  imagery  from  the  sensor  image  collector  simulation  laboratory  (UAV  ground 
station)  to  the  battle  management  station  (O'*!  platform)  where  it  is  processed  and 
disseminated  to  the  weapons  platform  aircraft  displays  (Shooter).  The  mission  computer 
and  display  console  workstations  hosting  the  Open  System  Architecture  (OSA)  capability 
will  represent  the  interaction  of  AW  ACS  as  a  Hardware-In-The-Loop  (HITL)  system.  An 
actual  DEMPC  mission  planner  and  image  analyzer  will  represent  the  interaction  of  the 
UAV.  A  SAR  processor  residing  on  an  SGI  Indigo-2  computer  will  provide  the  off-board 
sensing  element  for  the  UAV.  One  of  the  ITDL  dome  simulators  will  host  the  shooter 
aircraft  (advanced  fighter).  Common  databases  will  be  used  to  develop  correlated  images 
for  the  out-of-cockpit  visual  system  and  the  SAR  processor.  Other  participants  in  the 
scenario  will  provide  additional  workload  and  data  load  functions. 

For  the  actual  demonstration,  a  simulated  real-time  Synthetic  Aperture  Radar  (SAR) 
image  will  be  used.  The  SAR  image  will  be  taken  from  the  image  generator’s  visual 
database.  The  video  data  will  be  captured  and  processed  by  the  SGI  Indigo-2  sensor 
(SAR)  video  processor  and  transmitted  via  an  RS-170  video  link  to  the  image  analysis 
display  on  the  DEMPC  ground  station.  Additional  information  will  be  added  to  the 
image  which  will  then  be  transmitted  via  ATM  to  the  OSA  DEC  Alpha  AWACS 
operator’s  station.  The  resultant  image  will  then  be  passed  to  the  SGI  Onyx  cockpit 
display  processor  via  an  ATM  link  along  with  voice  communications  between  the  shooter 
and  the  Cl  platform.  The  information  displayed  in  the  shooter’s  cockpit  will  be  used  as 
targeting  information. 
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8.1,  AWACS-UAV-Fighter  Subsystem  Integration 

The  Integrated  Battlespace  Simulation  (IBS)  system  implementation  task  puts  all 
subsystems  together  into  an  IBS  system  for  the  final  demonstration.  Major  subtasks 
include  ATM  link  to  fighter  dome,  fighter  station  interfaces  to  ATM  and  Distributed 
Interactive  Simulation  (DIS)  networks,  Toshiba  big  screen  installation,  UAV  station 
(DEMPC)  interfaces  to  ATM  and  DIS  networks,  SAR  image  processing  and/or  transfer  to 
ATM,  and  IBS  scenario  demonstration. 

ATM  link  to  fighter  station  (F-2  dome):  We  evaluated  a  PCI-bus  ATM  adapter  for  the 
SGI  Onyx-2  to  support  the  ATM  link  to  the  advanced  fighter  dome  and  selected  the 
FORE  Systems’  PCA-200EUX  ATM  adapter.  The  ATM  adapter  (PCIbus-based)  was 
installed  into  the  SGI  Onyx-2  workstation  and  configured  as  a  fighter  platform  using 
ATM  LAN  emulation  and  classical  IP  over  ATM  schemes.  In  parallel,  the  Mojo 
workstation  (simulated  fighter)  was  significantly  improved,  so  that  it  now  represents  a 
simplified  fighter  station  with  a  joy-stick  controller.  This  mojo  station  can  be  used  as  a 
back-up  advanced  fighter  in  the  integration  and  testing  in  case  the  fighter  dome  is  not 
available. 

Large  Flat  Panel  Display  (FPD)  screen  installation:  We  obtained  the  Toshiba  driver 
required  for  the  FPD  screen  and  verified  its  operation.  The  required  DEC  Alpha  Kernel 
was  built  with  the  new  Toshiba  driver.  The  new  test  driver  was  installed  into  the  DEC 
Alpha  500  workstations  and  the  functionality  was  fully  tested. 

AWACS  OSA  compiler  upgrade:  The  AW  ACS  OSA  compiler  has  been  upgraded  from 
ADA-83  to  ADA-95  in  ITDL.  This  ADA-95  upgrade  will  provide  the  AWACS  platform 
(mission  computer)  with  enhanced  operational  capabilities.  The  ADA-95  also  provides 
an  additional  capability  of  incorporating  virtual  reality  networking.  Since  the  single  SGI 
Onyx-2  workstation  (Osprey  in  F-2  dome)  serves  two  functions  (i.e.,  one  as  a  fighter 
platform  and  another  as  a  simulation  manager  station)  there  is  a  need  for  “virtual  link” 
network  technology.  The  “VR-Link”  (by  Mak  Technologies,  Inc.)  is  a  line  of  software 
product  that  is  used  for  the  demonstration  of  distributed  synthetic  environments. 

SAR  image  transfer  to  UAV-AWACS-fighter:  The  test  files  of  SAR  images 
(preprocessed  image)  was  developed  and  kept  on  the  UAV  (DEMPC)  platform.  The 
SAR  image  file  transmission  was  successfully  tested  from  UAV  (DEMPC)  to  the 
AWACS  station  (mission  computer)  over  the  ATM  network.  Subsequently,  the  SAR 
image  file  transmission  was  also  tested  from  the  UAV  via  the  AWACS  to  the  fighter 
station  in  the  F-2  dome. 


88 


8.2.  Integrated  Battlespace  Simulation 

The  battlespace  simulation  demonstration  scenario  is  derived  from  the  Joint  Suppression 
of  Enemy  Air  Defense  (JSEAD)  program.  It  involves  a  conflict  between  two  regional 
powers  that  have  evolved  into  an  active  combat  situation.  The  allied  forces  are  deployed 
in  the  area  supporting  a  defensive  coalition.  The  demonstration  events  occur  during  the 
early  days  of  the  conflict,  and  depict  JSEAD  activities  leading  to  the  achievement  of  air 
supremacy.  Within  this  environment,  enemy  forces  can  generate  counter-air  actions  (air- 
to-air,  surface-to-air)  and  also  be  capable  of  conducting  land,  air  and  naval  combat 
operations.  The  demonstration  scenario  covers  the  following  major  phases  of  activity: 

(1)  Allied  air  forces  are  conducting  coordinated  attacks  against  enemy  air  defense  assets 
and  associated  command  and  control  elements  as  the  preliminary  step  toward  achieving 
air  superiority  in  theater. 

(2)  AWACS  uses  the  off-board  resource  data  as  well  as  on-board  sensors  to  detect  and 
target  threat  emitters,  and  initiates  strike  operation  with  available  air-ground  assets. 

(3)  Advanced  fighters  engage  threat  emitter  sites. 

(4)  AWACS  coordinates  follow-on  activities  against  other  enemy  air  defense  assets  (e.g., 
fighter  aircraft). 

For  demonstration  purposes,  the  scenario  has  been  established  in  the  Southwest 
CONtinental  United  States  (CONUS)  to  take  advantage  of  capabilities  that  exist  in  the 
ITDL  (e.g.,  terrain  databases).  The  scenario  map  shows  the  locations,  flight  paths,  and 
relative  geometry  of  participants. 

A.  Scenario  Map: 

A  map  of  the  demonstration  scenario.  Figure  8.2-1,  shows  nominal  emitter  locations  for 
initial  planning  purposes.  Orbits  of  AWACS  and  Combat  Air  Patrol  (CAP)  fighters  are 
shovra  as  ellipses  on  the  map.  Routes  for  ATO-designated  missions/targets  are  shown  as 
arrows  representing  axes  of  approach.  Details  for  individual  entities  vvdll  be  updated  and 
refined  as  the  scenario  design  is  completed.  The  locations  of  several  support  assets, 
including  ships,  are  also  shown;  however,  these  will  not  be  represented  as  real-time 
simulation  entities. 
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Figure  8.2-1:  Integrated  Battlespace  Simulation  Demonstration  Scenario  Map 


B.  Scenario  Timeline: 

The  overall  timeline  for  the  Phase  4  scenario  is  shown  in  Figure  8.2-2.  It  shows  the  key 
participants  and  the  major  activities  that  occur  within  the  demonstration.  Prior  to  the  start 
of  the  simulation,  some  Surface-to-Air  Missile  (SAM)  threats  have  been  suppressed 
during  an  initial  wave  of  JSEAD  strikes.  Defensive  fighters  have  been  pushed  up  to 
counter  any  enemy  retaliatory  strikes,  including  cruise  missile  strikes  launched  from 
ground,  surface,  and  air  platforms. 

At  the  time  of  simulation  start  (t=to),  the  AWACS  has  been  on  station  for  several  hours. 
The  AWACS  has  an  established  air  picture  that  shows  the  fighters  (tracks  with  ID),  a 
special  point  for  the  air  defense  unit,  a  KC-135  tanker  orbiting  to  the  theater  (optional) 
and  ingress  fighters  on  ATO-directed  JSEAD  missions.  The  major  events  that  occur  over 
time  in  the  scenario  are  as  follows. 
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Figure  8.2-2:  Integrated  Battlespace  Simulation  Demonstration  Scenario  Timeline 


Start  of  Scenario: 

The  enemy  threat  SAM  sites  that  has  survived  initial  JSEAD  strikes  continues  activity. 

Event  1 :  Fighter  positioned  about  hundred  miles  from  targets. 

Event  2:  SA-10  SAM  target  begins  operation  with  sporadic,  intermittent  emission 

pattern. 

Events:  AW  ACS  identifies  new  threat  emitter,  retasks  airborne  UAV,  and  plans  for 
strike. 

Event  4:  AW  ACS  identifies  threat  emitter  and  diverts  Air  Tasking  Order  (ATO)- 
directed  fighter. 

Event  5:  AW  ACS  notifies  Joint  Force  Air  Component  Commander  (JFACC)  of  action 
and  monitors  strike. 

Event  6:  Groimd  UAV  controller  uplinks  SAR  image  of  SAM  enemy  missile  site  to 
AWACS. 

Event  7:  The  fighter  receives  divert  tasking  and  SAR  image  of  target  from  AWACS, 
conducts  strike,  and  commences  egress  from  enemy  airspace. 

End  of  Scenario: 

AWACS  detects  enemy  fighters  reacting  to  strike. 
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9. 


AWACS  NETWORK  ARCHITECTURE  TRADE  STUDY  (TASK  6) 


A  trade  study  of  the  on-board  networks  within  the  existing  AWACS  programs  was 
performed.  This  trade  study  also  includes  the  off-board  network;  the  survey  and  future 
works  on  wireless  ATM  technologies  -  wireless  satellite,  wireless  terrestrial,  and  wireless 
mobile  ATM. 

9.1.  ATM  Alternatives 

The  major  criteria  for  the  selection  of  network  technology  involve  performanee  factors 
such  as  achievable  throughput  and  delay,  operational  features,  product  availability, 
compatibility  with  higher  layer  protocols,  upgradability,  and  cost  and  maintainability.  In 
this  section,  the  ATM  alternative  network  technologies  are  described.  These  include 
mainly  Fibre  Channel,  Gigabit  Ethernet,  and  Fast  Ethernet. 

9.1.1.  Fibre  Channel  Network 

Fiber  Channel  is  a  network  type  whose  main  market  niche  has  been  in  the  high-speed 
transfer  of  data  from  disks  to  a  processor.  For  such  an  application.  Fiber  Channel  has 
demonstrated  speeds  on  the  order  of  800  Mb/s  or  100  MB/s.  This  is  many  times  faster 
than  ultra  wide  SCSI  that  is  rated  at  40  MB/s.  Besides  speed,  another  advantage  of  Fiber 
Channel  is  that  the  cable  length  is  not  as  restrictive  as  SCSI  (comparing  with  ultra  SCSI 
cable  lengths  of  less  than  1 .5  m).  The  main  features  of  the  Fibre  Channel  network  are 
summarized  as  follows: 

•  ANSI  X3.230  Standard  mainly  for  channel  operation  up  to  1 .062  Gbps. 

•  High-speed  data  communications  coimections:  channel  and  network. 

•  High  performance  point-to-point  serial  data  channel. 

—  133  Mbps  to  1 .062  Gbps  per  direction. 

—  2.12  Gbps,  4.24  Gbps  specified  in  FC-PH-2, 3. 

•  5  -layer  Protocol  Stack  (F igure  9.1.1). 

—  FC-0:  Physical  interface  and  media . 

—  FC- 1 ;  T ransmission  protocol . 

—  FC-2:  Signaling  protocol. 

—  FC-3;  Common  services. 

—  FC-4:  Upper  Layer  Protocols  (ULP)  mapping. 

•  Support  multiple  existing  protocol  interfaces. 

—  Channel:  SCSI,  HPPI,  Intelligent  Peripheral  Interface  (IPI),  and  Single  Byte 
Command  Code  Set  (SBCCS). 

—  Network:  IEEE  802.2  (LLC),  IP,  ATM  AAL-5,  Link  Encapsulation  (FC-LE). 
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Figure  9.1.1:  Fibre  Channel  Protocol  Stacks 
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Advantages  of  Fibre  Channel: 

•  Currently  only  technology  with  physical  layer  standard  at  gigabit  speed;  133  Mbps 
to  1 .062  Gbps  per  direction. 

•  Support  both  channel  and  network  connections;  mainly  for  high-speed  data 
transport  channel  between  processors  and  peripherals. 

•  Support  multiple  existing  protocol  interfaces;  SCSI,  HPPI,  IPI,  SBCCS,  IEEE  802.2 
(LLC),  IP,  ATM  AAL-5,  Link  Encapsulation  (FC-LE). 

•  Scalable  connections;  16  million  nodes  on  a  single  fabric  (vs.  16  nodes  in  SCSI). 

Disadvantages  of  Fibre  Channel: 

•  Product  availability. 

•  Product  interoperability, 

•  Potential  concern  about  throughput  performance. 
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9.1.2.  Gigabit  Ethernet  Network 

Gigabit  Ethernet  preserves  the  fundamental  concepts  of  standard  Ethernet  framing.  It 
complies  v^th  the  IEEE  802.3  standard  for  frame  format  and  minimum  and  maximum 
frame  size.  However,  the  physical  layer  is  different.  It  provides  1  Gbps  bandwidth  for 
campus  networks  as  well  as  the  simplicity  of  Ethernet  at  lower  cost  than  many  other 
technologies  of  comparable  speed.  It  will  offer  a  natural  upgrade  path  for  current 
Ethernet  installations,  leveraging  existing  end  stations,  management  tools  and  training. 

Gigabit  Ethernet,  like  Fast  Ethernet  (in  section  9.1.3),  borrows  an  established  physical 
layer  standard  from  another  technology.  While  Fast  Ethernet  has  adopted  a  version  of  the 
FDDI  physical  layer  standard.  Gigabit  Ethernet  adopted  a  modified  version  of  the  ANSI 
X3T11  Fibre  Channel  physical  layer  standard  (FC-0).  Note  that  Fibre  Channel  is 
currently  the  only  technology  that  supports  gigabit  speeds  and  it  currently  supports  rates 
up  to  4.268  Gbps.  Gigabit  Ethernet  employs  the  same  Carrier  Sense  Multiple  Access 
with  Collision  Detection  (CSMA/CD)  protocol,  same  frame  format  and  same  frame  size 
as  its  predecessors. 

•  IEEE  802. 3z  Standard  for  Ethernet  operation  at  1  Gbps. 

•  Support  from  Gigabit  Ethernet  Alliance  (GEA);  80+  member  companies. 

•  Preserve  the  fundamental  concepts  of  standard  Ethernet. 

—  Ethernet  framing. 

—  Frame  format,  maximum  and  minimum  frame  size. 

•  Physical  layer  standard  (Figure  9. 1 .2). 

—  Adopt  ANSI  X3T1 1  Fibre  Channel  physical  layer  (FC-0)  standard  because 
only  FC  currently  supports  gigabit  speeds  (up  to  4.268  Gbps). 

—  Adopt  FC’s  encode/decode  layer  (FC-1);  8B/10B  coding  technique. 

•  Support  both  half-duplex  and  full-duplex  operation. 

—  Gigabit  Ethernet  is  most  effective  in  the  full-duplex,  point-to-point  mode 
where  full  bandwidth  is  dedicated  between  two  points. 

—  Switch  has  an  option  of  half-  or  full-duplex  on  a  port-by-port  basis;  allow  for 
migration  from  shared  to  point-to-point,  full-duplex  segments. 

•  Optional  flow-control  mechanism  is  being  defined  under  IEEE  802.3x. 
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Figure  9.1.2:  Gigabit  Ethernet  Protocol  Stacks 


Gigabit  Ethernet  Operation:  Full-Duplex 

•  Use  IEEE  802. 3x  full-duplex  specification. 

•  Ideal  for  backbones,  high-speed  server  or  router  links. 

•  Point-to-point  connections  only;  not  for  shared-port  connections,  such  as  repeater  of 
hub  port;  CSMA/CD  is  not  required  and  disabled. 

•  Use  IEEE  802.3x  frame-based  flow  control;  similar  to  XON/XOFF. 

Gigabit  Ethernet  Operation:  Half-Duplex 

•  Ideal  for  shared  multistation  LANs;  two  or  more  end  users  share  a  single  port. 

•  Use  standard  Ethernet  CSMA/CD  access  method. 

•  Gigabit  Ethernet  performance  is  degraded. 

•  Sensitive  to  segment  length  due  to  the  use  of  CSMA/CD  protocol. 

•  Standard  slot  time  for  Ethernet  frames  is  too  short  to  run  a  100m  cable  when 
passing  64-Byte  frame  at  gigabit  speeds;  timing  is  extended  with  no  frame  size 
change  to  guarantee  5 12-Byte  slot  time  using  “Carrier  Extension.” 

•  IEEE  802.3  specification  requires  500m  over  multi-mode  fiber  at  1.0  Gbps;  500m 
(MMF),  3km  (SMF),  25m  (STP  Coax),  future  100m  (UTP  Cat  5). 

•  Gigabit  Ethernet  is  limited  to  one  repeater  per  segment  (e.g.,  2  for  Fast  Ethernet). 
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Advantages  of  Gigabit  Ethernet: 

•  Use  fundamental  Ethernet  concepts:  Ethernet  is  the  mainstream  network. 

•  Support  same  frame  format  and  size  as  Ethernet. 

•  Support  existing  network  operating  systems,  network  management,  and 
applications;  standard  Ethernet  CSMA/CD  protocol. 

•  Potential  for  interoperability  and  backward  compatibility. 

•  Potential  for  low-cost  products. 

•  Potential  for  large,  stable  Ethernet  vendors  support. 

•  Potential  for  low  risk  and  existing  investment  preservation. 

Disadvantages  of  Gigabit  Ethernet: 

•  Gigabit  Ethernet  products  just  beginning  to  be  available. 

•  Gigabit  Ethernet  is  not  fully  standardized. 

9.1.3.  Fast  Ethernet  Network 

Fast  Ethernet  (IEEE  802.3u)  is  a  faster  version  of  Ethernet  operating  at  100  Mbps.  Fast 
Ethernet  maintains  the  concept  of  the  IEEE  802.3  protocol  and  increases  the  throughput 
tenfold  by  speeding  up  the  MAC.  The  physical  layer  signaling  definition  for  Fast 
Ethernet  is  based  on  the  FDDI  standard.  Fast  Ethernet  requires  either  a  hub  or  a  switch  if 
any  more  than  two  devices  are  to  be  interconnected.  Fast  Ethernet  can  operate  with  either 
Category  5  twisted  pair  wire  or  optical  fiber. 

Current  technology  is  such  that  the  network  interface  cards  that  allow  a  device  to 
communicate  over  Ethernet  are  implemented  with  auto-sense  ASICs.  It  operates  at  either 
10  Mbps  or  100  Mbps  depending  on  the  connection  made.  In  this  manner,  a  hub  or 
switch  can  have  different  speed  devices  connected  to  it.  In  the  case  of  hubs,  if  a  device 
communicates  at  only  10  Mbps  then  the  device  it  communicates  with  must  also  be  at  10 
Mbps  for  that  communication  only.  In  the  case  of  switches,  normally  a  port  transmits  at 
its  maximum  speed  of  100  Mbps  even  though  the  data  are  sent  to  the  destination  port  at  a 
slower  speed  of  10  Mbps.  The  Fast  Ethernet  speed  of  100  Mbps  is  a  half-duplex  speed, 
and  the  full-duplex  speed  would  be  200  Mbps  per  port. 

A  concern  about  Fast  Ethernet  technology  relates  to  LAN  topology  considerations  and  the 
possible  need  to  rewire  perhaps  a  portion  of  the  enterprise.  The  lOBase-T  supports  a 
diameter  (the  distance  between  farthest  nodes)  of  2.5  km.  By  contrast,  in  a  single 
segment,  the  100Base-T  has  a  maximum  collision  domain,  including  repeaters,  of  only 
205  m  (half-duplex  operation,  balanced  copper  links,  and  no  margin).  Another  concern 
relates  to  the  fact  that  the  specification  sets  a  two-hub/repeater  maximum  (with  an  inter¬ 
repeater  distance  not  to  exceed  5  m)  for  latency  reasons.  Repeaters  are  permitted  within  a 
single  collision  domain  to  provide  the  maximum  path  length.  The  two-repeater  limit 
implies  a  single-level  hub  structure,  and  since  Fast  Ethernet  hubs  on  the  market  support 
24  ports  per  hub,  this  results  in  a  network  with  at  most  48  stations.  However,  new 
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repeater  chips  under  development  will  facilitate  the  hubs  supporting  100  Fast  Ethernet 
ports  per  hub.  These  hubs  can  then  be  connected  to  form  a  two-hub  network  of 
approximately  200  nodes. 

9.2.  Architecture  Choice  of  Existing  AW  ACS  Programs 

Existing  AWACS  programs  have  selected  various  network  architectures  tailored  for  their 
own  requirements  and  applications.  These  include  ATM,  FDDI,  Fast  Ethernet,  Gigabit 
Ethernet,  and  Fibre  Channel.  The  network  selection  for  existing  programs  is  as  follows: 

1 .  Advanced  AWACS  OSA  program: 

•  Computer  and  display  consoles:  high-end  workstation. 

•  Network:  ATM,  Ethernet  (Redundant). 

2.  US  AWACS  Extend  Sentry  Step  1  program: 

•  Computer  and  display  consoles:  CC-2E ,  WSC/SDC. 

•  Network:  Fibre  Channel. 

3.  NATO  Midterm  program: 

•  Computer  and  display  consoles:  high-end  workstation. 

•  Network:  Gigabit  Ethernet. 

4.  EFX98  program: 

•  Computer  and  display  consoles:  high-end  workstation. 

•  Network:  ATM,  Ethernet  (Redundant). 

5.  Wedgetail  program: 

•  Computer  and  display  consoles:  high-end  workstation. 

•  Network:  Fast  Ethernet. 

6.  NIMROD  program: 

•  Computer  and  display  consoles:  high-end  workstation. 

•  Network:  Fast  Ethernet. 

9.2.1.  US  Advanced  AWACS  Open  Systems  Architecture 

Boeing  is  currently  developing  implementations  of  mission  avionics  for  future  advanced 
C"*!  aircraft,  including  future  Advanced  AWACS.  Advanced  AWACS  open  systems 
architecture  (OSA)  program  is  an  exEunple.  The  Advanced  AWACS  OSA  program  has 
chosen  the  FDDI  and  redundant  Ethernet  as  the  mission  computing  LAN.  Boeing  has  a 
prototype  AWACS  implementation  in  the  laboratory,  based  on  the  Boeing-developed 
OSA  design  approach.  This  prototype  has  been  developed  in  conjunction  with  U.S.  Air 
Force  AWACS  personnel  and  is  based  on  COTS  technology.  Figure  9.2.1  shows  the 
OSA  design  for  the  current  Advanced  AWACS.  Communications  between  the  mission 
computer  and  display  consoles  are  accomplished  over  the  separate  Ethernet  and  FDDI 
networks.  A  future  AWACS  will  require  advanced  mission  avionics  architecture  to  meet 
the  increased  information  processing  requirements  of  future  missions. 
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Boeing  is  developing  a  COTS-based  OSA  display  and  control  system  to  enable  the 
AWACS  to  add  new  functions  needed  for  future  missions  such  as  theater  air  (missile) 
defense,  on-board  and  off-board  multi-sensor  integration,  and  theater  battle  management 
(e.g.,  JACE,  air-to-ground  mission  support,  dynamic  ATO).  Key  hardware  features  of 
the  OSA  display  and  control  system  include: 

a.  Lightweight  composite  structure. 

b.  Open  architecture  (VME  DEC  Alpha-based  solution). 

c.  Simplified  Human-Computer  Interface  (HCI). 

d.  Large  CRT  (1024  x  1280  pixel  resolution). 

e.  Trackball/mouse  and  QWERTY  keyboard. 

f.  Function  keypad. 

g.  Floppy  disk  for  mission  data. 

h.  CD  ROM  for  tech  orders,  etc. 

i.  Retractable  keyboard/keypad. 

j.  Designed  to  replace  E-3  Situation  Display  Console  (SDC). 

k.  Withstand  16g  crash  loads. 

l.  Growth  margin. 
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Key  features  of  the  simplified  human-computer  interface  include: 

a.  X  Windows,  MOTIF,  OPENGL  displays. 

b.  Display  designed  to  minimize  operator  fatigue  during  long  missions. 

c.  Video/SAR  imagery  in  tactical  displays. 

d.  Reduced  operator  workload. 

e.  Multiple  tabular  displays,  tactical  displays. 

f.  Supports  multiple  environments. 

g.  Raster  and  elevation  maps. 

h.  Map  overlaid  with  video. 

I.  Large  color  display. 

j.  Detailed  map  and  weather  displays. 

9.2.2.  US  AWACS  Extend  Sentry  Step-1  Architecture 

The  U.S.  AWACS  Extend  Sentry  program  has  chosen  the  Fibre  Channel  as  the  mission 
computing  LAN  as  opposed  to  Fast  Ethernet,  Gigabit  Ethernet,  and  ATM.  Fibre  Channel 
is  ANSI-X3.230  Standard  mainly  for  chaimel  operation  up  to  1.062  Gbps.  Fiber  Channel 
is  designed  to  be  able  to  handle  multiple  types  of  data  and  protocols  and  its  main  market 
niche  has  been  in  the  high-speed  transfer  of  data  from  disk  farms  to  a  processor. 

The  main  features  of  Fibre  Channel  technology  are  as  follows: 

•  Currently,  the  only  technology  with  a  physical  standard  at  a  gigabit  speed  of  133 
Mbps  to  1 .062  Gbps  per  direction 

•  Support  both  chaimel  and  network  connections,  mainly  for  high-speed  data  transport 
channel  between  processors  and  peripherals. 

•  Support  multiple  existing  protocol  interfaces. 

•  Scalable  coimections  up  to  16  million  nodes  on  a  single  fabric. 

The  baseline  configuration  for  U.S.  AWACS  Extend  Sentry  program  is  as  follows: 

•  Ancor  Fibre  Channel  switch  as  the  baseline  configuration. 

•  Systran  Fibre  Channel  NICs  and  driver  SW  installed  on  the  CDC  Equipment. 

•  New  NIC  &  Driver  for  DASA  to  be  developed. 

•  Fiber  optic  cables  to  all  devices  -  SC  connectors  on  NICs  and  switch. 

Although  there  were  some  concerns  on  the  product  availability,  product  interoperability, 
and  throughput  performance,  Boeing  had  eventually  resolved  all  these  potential  concerns. 
In  addition,  Boeing  successfully  developed  a  ruggedized  switch  design  for  the  airplane 
environment  to  pass  strict  qualification  testing.  Figure  9.2.2  shows  a  diagram  of  US 
AWACS  Extend  Sentry  Step-1  network  architecture. 
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9.2.3.  US  Expeditionary  Force  Experiment  AW  ACS  Architecture 

The  1998  Expeditionary  Force  Experiment  (EFX98)  demonstration  involves  data/video 
broadcasting  from  the  ground  station  to  multiple  mobile  platforms  via  a  relaying  satellite. 
The  ground-to-air  data  rate  is  1.544  Mbps  via  a  relaying  Ku-band  satellite  and  the  air-to- 
ground  transmission  date  rate  is  4.8  kbps  via  UHF  satellite.  The  Yurie  Systems’  LDR-50 
ATM  Access  Concentrator  weis  used  for  the  ATM  WAN  switch  and  an  IBM  8260 
Multiprotocol  N-way  Switch  was  used  for  the  ATM  LAN  switch.  The  end  systems  were 
SUN  Ultrasparc  Il-xi  workstations  running  Solaris  2.5.1  and  Pentium  11-400  PCs  running 
NT  4.0.  Figures  9.2.3-1  and  92.3-2  show  the  network  architecture  of  EOC  and  JFACC 
aircraft,  respectively.  The  AW  ACS  aircraft  of  the  EFX98  demonstration  deploys  the  US 
AW  ACS  Extend  Sentry  Step-1  network  architecture  that  uses  a  Fibre  Channel  LAN 
switch.  As  shown  in  Figure  9.2.3-3,  there  is  a  need  for  a  gateway  to  convert  between 
ATM  (also  Ethernet  in  EFX98)  and  Fibre  Channel  protocols.  The  Multi-Switching 
Service  (MSS)  router  module  of  an  IBM  8260  Multiprotocol  N-way  Switch  performs  this 
function. 


Figure  9.23-1:  EOC  Aircraft  Architecture  for  EFX98  Demonstration 


Figure  9.2.3-2:  JFACC  Aircraft  Architecture  for  EFX98  Demonstration 
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2:  AWACS-FC  (Redundant) 

3:  VLAN-AWACS  (TCP/IP  from  Yurie  Port  2 10B-T  Ethernet) 
4:  ULAN-AWACS  (UDP/IP  from  Yurie  Ports  10B-T  Ethernet) 


Figure  9.2.3-3:  AW  ACS  Aircraft  Architecture  for  EFX98  Demonstration 


9.2.4.  NATO  AW  ACS  Midterm  Architecture 

NATO  AWACS  program  has  chosen  the  Gigabit  Ethernet  (Figure  9.2.4)  as  the  mission 
computing  LAN  as  opposed  to  Fast  Ethernet,  ATM,  and  Fiber  Channel.  Gigabit  Ethernet 
is  a  faster  version  of  Fast  Ethernet,  operating  at  1  Gbps,  and  operates  both  over  copper 
wires  for  short  distances  3ind  optical  fiber  for  longer  distances.  The  Gigabit  Ethernet 
standard  is  complete  and  the  switch  products  become  available. 

The  use  of  a  LAN  has  a  primary  purpose  to  provide  an  efficient  flow  of  data  between 
AWACS  Mission  Computer  (AMC)  and  other  units.  Many  factors  were  considered  for 
this  choice  including  product  maturity,  market  position,  product  suppliers,  product 
performance,  and  the  ability  of  products  to  work  in  the  NATO  system.  Risk  of  required 
modification  of  COTS  equipment  and/or  software  for  the  proper  functionality  was  also 
considered.  The  important  selection  criteria  are; 

•  Achievable  bandwidth. 

•  Broadcast  and  multicast  capability:  Mission  Computer  (MC)  software  uses  multicast 
when  transferring  track  data  to  the  consoles. 

•  Availability  of  COTS  hardware  and  software. 

•  Compatibility  with  TCP/IP  and  ORBIX. 

•  Operational  reliability  and  fault  tolerance. 


103 


•  Production  and  maintenance  costs. 

•  Scalability  and  upgradability. 

•  CPU-to-CPU  latency  and  jitter. 


There  is  a  great  difference  between  minimum  and  maximum  CPU-to-CPU  latency.  In  the 
case  of  minimum  latency,  all  the  candidates  have  latencies  under  20  microseconds,  which 
is  considered  trivial  as  a  discriminator  for  a  program.  The  maximum  latency  is  dependent 
on  heavily  loaded  network  conditions  where  many  ports  are  trying  to  output  on  the  same 
port.  The  protocols  that  have  the  smallest  cell  or  that  can  operate  at  gigabit  speeds  will 
have  the  smaller  latencies.  If  we  assume  a  1500-Byte  packet  (e.g.,  Ethernet),  the 
worstcase  latency  is  estimated  for  1  ms. 

The  required  bandwidth  estimate  for  the  NATO  Midterm  Program  is  total  raw  data  traffic 
of  92  Mbps.  This  includes  25  Mbps  for  T&C  results  and  checkpoint;  22  Mbps  per  SDC 
for  live  mode  displays,  tracks,  sensors,  maps,  and  documents;  33  Mbps  for  X-checkpoint; 
11  Mbps  for  normal  and  replay  recording;  and  1  Mbps  for  printers.  Thus,  the  total 
throughput  of  200  Mbps  is  required  with  50%  margin  of  error  and  70%  efficiency. 
Gigabit  Ethernet  provides  the  best  overall  performance/cost  ratio  and  therefore  is  the  best 
choice  for  the  NATO  Midterm  program. 


Figure  9.2.4:  NATO  AWACS  Midterm  Network  Architecture 
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9.2.5.  Australia  AW  ACS  Wedgetail  Architecture 

The  baseline  architecture  of  the  Wedgetail  mission  system  was  based  on  the  ATM  LAN 
network  (Figure  9.2.5).  Recent  changes  in  requirements  of  the  baseline  mission  system 
removed  a  need  of  digitized  audio  transport  over  LAN  and  assigned  it  to  a  separate  set  of 
hardware  items  called  the  ICS.  Since  there  is  no  requirement  for  continuous  digitized 
audio  or  video  on  the  Wedgetail  LAN  the  guaranteed  bandwidth  is  no  longer  an  issue. 
Thus,  there  is  a  need  to  determine  whether  or  not  ATM  would  still  provide  the  best 
Wedgetail  solution. 

The  major  traffic  patterns  are  as  follows: 

•  10  Mbps  for  data  processing  that  sends  data  to  all  consoles. 

•  4  Mbps  for  centralized  map  server. 

•  4  Mbps  for  sensor  data  and  other  types  of  data. 

•  8  Mbps  for  data  processing  that  sends  checkpoint  data. 

•  4  Mbps  for  Radar,  ESM,  and  EWSP. 

•  4  Mbps  for  data  output  communication  links. 

•  3  Mbps  for  ICS  audio  record  output. 

•  1  Mbps  for  data  processing  to  CEC. 

The  data  processing  LAN  input  and  output  is  by  far  the  highest  data  traffic  at  6  Mbps  (10 
Mbps  with  CEC  option)  and  18  Mbps,  respectively.  It  is  proposed  to  have  two  LAN 
switches  with  a  separate  port  from  the  data  processing  CPU  to  each  switch. 

In  recommending  a  specific  LAN  type  and  hardware  for  the  Wedgetail  mission  system, 
the  following  important  selection  criteria  were  considered  in  order  of  priority: 

•  Throughput. 

•  Compatibility  with  higher  level  protocols. 

•  Deployment  history  for  Boeing  programs. 

•  Ruggedization. 

•  Reliability. 

•  Upgradability. 

•  Availability. 

•  Cost. 

•  Weight. 

•  Latency. 

•  Multimedia  capability. 
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Figure  9.2.5:  Wedgetail  AW  ACS  Mission  System  Network  Architecture 


9.2.6.  British  NIMROD  Architecture 

The  basic  TCS  system  has  dual  Input/Output  Processors  (lOP)  mission  computers  and  up 
to  8  workstations.  These  are  interconnected  using  100Base-T  (IEEE  802.3u)  with  two 
switching  hubs  and  also  have  redundant  interconnects.  The  rest  of  the  system  consists  of 
several  sensors  (e.g.,  radar,  ESM,  EO,  acoustics).  These  sensors  are  connected  to  the 
lOPs  by  MIL-STD-1553  for  the  most  part,  so  that  the  LAN  can  be  used  mainly  for  the 
central  computing  and  displays. 

A.  FDDI-Based  Design: 

The  baseline  TCS  computer  bus  architecture  is  shown  in  Figure  9.2.6-1.  This 
configuration  includes  an  FDDI  bus  (100  Mbps)  for  data  between  workstations  and  lOPs, 
and  an  internal  lOBase-2  Ethernet  bus  (10  Mbps)  that  interconnects  the  workstations  and 
lOPs,  as  well  as  the  printers  and  acoustic  video  converter  (that  captures  acoustic  video 
and  converts  it  to  Ethernet  data  for  the  printers).  A  second  Ethernet  bus  provides 
connectivity  to  elements  external  to  the  TCS  (acoustic  system,  ESM,  and  DASS). 
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Figure  9.2.6-1:  FDDI-Based  TCS  Computer  Data  Bus  Architecture 


Basic  FDDI  architecture  involves  dual  counter-rotating  rings  to  achieve  fault  recovery 
from  a  failed  station.  The  difficulty  with  this  arrangement  is  maintaining  the  network  if 
two  or  more  non-contiguous  stations  are  not  operational  (for  example,  not  powered  up). 
In  the  baseline  design,  this  situation  is  avoided  by  using  concentrators,  which  perform  the 
function  of  inserting  or  removing  individual  stations  from  the  network.  An  alternative  is 
the  use  of  optical  bypass  relay  at  each  station;  however,  it  introduces  optical  power  loss 
and  probably  decreases  system  reliability.  Since  the  concentrators  provide  the  fault 
recovery,  stations  are  connected  using  the  Single  Attachment  Station  (SAS) 
configuration.  Two  interconnected  concentrators  are  used,  which  provides  a  partial 
measure  of  redundancy.  If  either  concentrator  fails,  the  remaining  unit  interconnects  a 
portion  of  the  workstations  to  an  lOP.  Note  that  the  current  ESM  SCD  specifies  a  Fast 
Ethernet  interface,  which  is  not  supported  in  the  baseline. 

B.  Fast  Ethernet-Based  Design: 

Replacement  of  FDDI  with  100Base-T  Fast  Ethernet  would  involve  replacement  of  FDDI 
concentrators  with  Ethernet  hubs,  and  replacement  of  the  FDDI  VME  cards  with  Fast 
Ethernet  cards  (now  available  in  PCI  mezzanine  modules).  An  alternative  architecture 
based  on  Fast  Ethernet  is  given  in  Figure  9.2.6-2.  Both  FDDI  and  lOBase-2  Ethernet  bus 
#1  are  replaced  with  100Base-TX  (Fast  Ethernet).  The  lOBase-2  Ethernet  bus  #2  is 
retained,  though  the  connectivity  is  altered. 
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Figure  9.2.6-2:  Alternative  Fast  Ethernet-Based  Architecture 


Not  all  stations  on  the  bus  can  be  converted  to  Fast  Ethernet.  DASS  provides  only  a 
lOBase-T  Ethernet  interface.  Neither  offers  Fast  Ethernet  as  a  current  interface  option. 
To  serve  the  DMC  text  printer  and  the  hard  copy  color  recorder,  a  lOBase-T  Ethernet  is 
retained  in  the  architecture.  Two  uncoupled  Ethernet  hubs  are  used,  maintaining  a  degree 
of  bus  independence  (and  potential  redundancy).  One  hub  is  a  simple  shared  Ethernet 
device  and  another  hub  is  actually  a  lO/lOOBase-T  switching  hub.  This  is  required  to 
interface  the  lOBase-T  Ethernet  to  the  100Base-T  Ethernet  network.  Increasingly,  Fast 
Ethernet  becomes  a  viable  option  for  devices  that  offer  Ethernet.  Both  the  DEC  Alpha 
and  the  PowerPC  will  provide  Fast  Ethernet  for  the  CPU  network  port  in  later  versions. 

9.3.  Related  Works  on  Wireless  ATM 

The  wireless  link  is  generally  grouped  into  two  different  types:  wireless  satellite  link  and 
wireless  terrestrial  link.  Both  links  typically  have  higher  Bit  Error  Rate  (BER)  and  more 
dependent  bit  errors.  In  the  wireless  satellite  link,  the  higher  BER  is  due  to  the  low 
Signal-to-Noise  Ratio  (SNR)  exhibited  by  the  channel  at  reasonable  transmitter  power. 
The  forward  error  correction  coding  (e.g.,  convolutional  codes  with  Viterbi  decoding)  can 
be  used  to  reduce  the  BER  at  the  available  SNR.  In  the  wireless  terrestrial  link,  the 
higher  BER  and  burstiness  are  caused  by  channel  fading.  Again,  the  FEC  coding¬ 
interleaving  scheme  can  be  considered. 
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9.3.1.  Wireless  -  Satellite  ATM 


When  ATM  traffic  is  carried  over  wireless  satellite  links  in  commercial  and  military 
satellite  systems,  a  number  of  problems  arise.  The  major  problems  and  issues  are  as 
follows: 

•  ATM  protocols  were  designed  for  fiber-based  switch  links.  ATM  protocols  assume 
that  the  transmission  medium  has  a  very  low  Bit  Error  Rate  (BER)  of  10"’^  or  less  and 
that  bit  errors  occur  randomly.  Most  satellite  and  wireless  links  have  much  worse 
BER  (lO"^  to  10'*)  and  errors  tend  to  occur  in  long  bursts,  especially  when  Viterbi 
coding  is  used  in  the  Modem. 

•  An  ATM  cell  carries  a  5-Byte  header  that  includes  address  tags  such  as  virtual  path 
and  virtual  channel  identifiers  that  are  used  to  route  ATM  cells.  This  header  includes 
a  1  Byte  Header  Error  Control  (HEC)  that  can  correct  single-bit  errors  in  the  cell 
header  but  only  detect  multiple  bit  errors.  ATM  switches  typically  discard  cells  with 
detected,  uncorrectable  bit  errors.  Multiple  bit  errors  that  are  not  detected  cause 
misrouting  of  ATM  cells.  There  is  no  provision  for  correcting  bit  errors  in  the  cell 
payload  field.  While  this  scheme  works  well  over  high-quality  fiber  links,  it  does  not 
work  over  wireless  links.  The  header  error  correction  mechanism  is  useless  in  the 
satellite  and  terrestrial  wireless  enviromnents. 

•  Unlike  fiber  links,  the  satellite  links  have  BERs  that  tends  to  fluctuate  (10'^  to  10'*) 
over  time,  depending  on  atmospheric  conditions.  Typically,  the  satellite  links  are 
designed  for  the  worst  case  conditions,  although  the  BER  tends  to  remain  low  for  a 
large  portion  of  the  time.  Forward  Error  Correction  (FEC)  parameters  are  fixed  for 
the  worst-case  link  analysis.  This  results  in  a  large  loss  of  usable  bandwidth. 

•  The  available  bandwidth  over  satellite  links  is  limited  and  the  cost  of  bandwidth  is 
high.  ATM  has  a  large  overhead  per  cell  and  is  not  particularly  efficient  in  its 
utilization  of  transmission  bandwidth.  Techniques  to  maximize  ATM  throughput  over 
the  limited  bandwidth  satellite  link  are  desirable. 


The  demonstration  of  ATM  links  over  satellite  includes  numerous  testbeds  using 
geosynchronous  satellites  between  fixed  ground  stations.  Examples  include  programs 
sponsored  by  U.S.  DoD,  European  RACE,  NASA  ACTS,  and  various  private  testbeds 
sponsored  by  COMSAT,  Eutelsat,  Telesat,  and  others.  Most  of  the  known 
communications  between  ground  stations  to  date  has  been  done  using  the  satellite  in  a 
“bent-pipe”  configuration  where  the  satellite  simply  acts  as  a  relay  point  between  the  two 
end  stations. 

At  Boeing,  there  are  several  ongoing  satellite  programs  which  include  Teledesic  (known 
as  Tntemet-in-the-sky’),  Airborne  Information  Services  (AIS),  and  DoD’s  annual 
demonstrations  such  as  Joint  Worrier  Interoperability  Demonstration  (JWID)  and 
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Expeditionary  Force  Experiment  (EFX).  The  JWID97  demonstration  involved  data/video 
transmission  from  the  ground  station  to  a  single  platform  (SPECKLED  TROUT)  via 
satellite.  The  ground-to-air  data  rate  was  1.544  Mbps  via  a  relaying  Ku-band  satellite  and 
the  air-to-ground  transmission  date  rate  was  4.8  Kbps  via  the  INMARSAT  satellite.  The 
ATM  switches  used  were  the  Yurie  Systems’  LDR-50  ATM  access  concentrator.  Using 
the  Ku-band  we  have  built  up  an  ATM  satellite  simulation  testbed  (Figure  9.3.1).  The 
goal  of  the  testbed  is  to  demonstrate  a  transmission  of  ATM  wireless  traffic  over  a 
simulated  satellite  chaimel  between  two  fixed  stations  and,  in  the  future,  between  mobile 
stations. 


Figure  9.3.1:  ATM  Satellite  Network  Simulation  Testbed 


9.3.2.  Wireless  -  Terrestrial  ATM 

The  advent  of  wireless  ATM  technology  is  intended  to  provide  a  direct  extension  of  the 
core  ATM  network  and  services.  However,  the  realization  of  wireless  ATM  presents  a 
number  of  technical  challenges  that  need  to  be  resolved.  First,  there  is  a  need  for  the 
allocation  and  standardization  of  appropriate  radio  frequency  bands  for  broadband 
communications.  Second,  new  radio  technology  and  access  methods  are  required  to 
operate  at  high  speed.  Third,  location  management  must  be  capable  of  tracking  mobile 
terminals  as  they  move  around  the  network.  Fourth,  handoff  algorithms  must  be  capable 
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of  dynamically  reestablishing  virtual  circuits  to  new  access  points  while  ensuring  in 
sequence  and  loss-free  delivery  of  ATM  cells.  Finally,  wireless  ATM  should  provide 
uniformity  of  end-to-end  quality  of  service  guarantees.  Providing  such  guarantees, 
however,  is  difficult  during  periods  of  limited  bandwidth,  time-varying  channel 
characteristics,  and  terminal  mobility. 

The  ATM  Forum  created  (in  1996)  a  Wireless  ATM  (WATM)  working  group  to  extend 
ATM  technology  to  the  wireless  and  mobile  domain.  During  the  same  time  the  FCC 
announced  the  allocation  of  350  MHz  of  National  Information  Infrastructure  (Nil) 
SUPERNet  spectrum  in  the  5-GHz  band.  This  announcement,  with  spectrum-sharing 
rules  linked  to  high-speed  wireless  access,  opens  the  way  for  the  future  deployment  of 
cost-effective  radio  access  to  the  next-generation  Internet  and  broadband  ATM-based 
networks.  The  inherent  challenge  of  wireless  ATM  is  to  provide  ATM,  a  connection- 
oriented  protocol  developed  specifically  for  a  reliable  high-bandwidth  wired 
infrastructure,  along  with  its  negotiated  quality-of-service,  for  mobile  users  with  frequent 
breaks  and  makes  of  connections  over  a  shared,  unreliable,  and  limited-bandwidth 
wireless  medium. 

A  number  of  experimental  wireless  ATM  testbeds,  developed  by  NEC,  ORE,  NTT,  and 
Lucent  Technologies,  have  been  instrumental  in  promoting  the  idea  of  wireless  ATM. 
NEC  has  recently  completed  the  second  generation  of  their  prototype,  which  operates  at  8 
Mbps  in  the  2.4-GHz  ISM  band.  The  experimental  hardware  consists  of  laptops  with 
radio  ATM  interface  cards,  multiple  VME/i960  processor-based  Access  Points  (AP),  and 
mobility-enhanced  local  area  2.4  Gbps  ATM  switches.  A  dynamic  Time-Division 
Multiple  Access/Duplex  (TDMA/TDD)  medium  access  control  provides  explicit  support 
for  Constant  Bit  Rate  (CBR),  Variable  Bit  Rate  (VBR),  and  Available  Bit  Rate  (ABR) 
services  over  the  air  interface. 

At  Boeing,  several  programs  £ire  ongoing  related  to  extending  ATM  protocol  to  the 
wireless  environment.  The  wireless  ATM  testbed  is  one  example.  Using  the  ISM 
frequency  band  at  5.7  GHz,  we  have  built  up  broadcast  stations,  using  COTS  equipment, 
for  communicating  point-to-point  over  a  range  of  up  to  40  miles  depending  on  the 
antennas  used.  The  end  stations  consist  of  an  ATM  switch  and  associated  end  user 
workstations,  ATM  link  accelerator  (enhanced  error  correction  and  congestion  control), 
CSU/DSU  (remoting  the  modem/antenna  from  the  switch  via  industry  standard  Telco  T-1 
line),  and  wireless  spread-spectrum  modem.  The  goal  of  this  testbed  is  to  demonstrate 
transmission  of  ATM  wireless  traffic  between  two  fixed  stations  and  later  between 
mobile  stations.  Follow-on  work  using  this  testbed  will  involve  substituting  Boeing’s 
electronically-steered  Phased-Array  Antennas  (PAA)  for  the  COTS  conventional 
antennas  for  demonstration  of  TDMA-partitioned  wireless  ATM  traffic. 

9.3.3.  Wireless  -  Mobile  ATM 

With  the  development  of  ATM  as  a  leading  protocol  for  wired  broadband  networks,  along 
with  the  growing  interests  on  mobile  networking,  it  is  natural  that  wireless  or  mobile 
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extensions  of  the  ATM  protocol  be  considered.  The  introduction  of  wireless  access  and 
mobility  features  into  a  fixed  ATM  infrastructure  can  provide  the  seamless  end-to-end 
broadband  connectivity  to  mobile  end-users.  Considerations  of  ATM  mobility  to  date 
have  focused  primarily  on  applications  with  the  mobility  of  end-user  terminals;  the  ATM 
switches  are  fixed  while  the  end-user  terminals  are  mobile.  Another  class  of  applications 
deals  with  the  mobility  of  the  ATM  switch  itself,  where  a  network  segment  consisting  of 
one  or  more  ATM  switches  are  in  motion  with  respect  to  the  fixed  portion  of  the  network. 
An  example  of  this  application  involves  mobile  platforms  with  multiple  users  on-board, 
such  as  airplanes. 

Boeing  has  been  leading  the  industrial  effort  to  develop  a  mobile  platform  wireless  ATM 
technology  in  collaboration  with  IBM  through  the  ATM  Forum  Wireless  ATM  (WATM) 
workgroup.  Boeing  has  demonstrated  the  concept  of  mobile  ATM  communications  over 
satellite  through  DoD’s  1997  Joint  Worrier  Interoperability  Demonstration  (JWID97)  and 
the  Air  force’s  1998  Expeditionary  Force  Experiment  (EFX98)  demonstrations  (Figure 
9.3.3). 
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Figure  9.3.3:  Simplified  System  Configuration  of  EFX98  Demonstration 


Boeing  has  also  demonstrated  mobile  platform  ATM  hand-over  concepts  at  the  Defense 
Information  Systems  Agency  (DISA).  At  the  IEEE  1998  MILitary  COMmunications 
conference  (MILCOM’98)  in  October  1998,  a  variety  of  applications  (e.g.,  collaborative 
virtual  worksharing)  were  demonstrated  on  top  of  the  ATM  hand-over  concept. 
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EFX98  Demonstration:  The  EFX98  demonstration  involved  data/video  broadcast  from 
the  ground  station  to  multiple  mobile  platforms  via  a  relaying  satellite.  The  ground-to-air 
data  rate  was  1.544  Mbps  via  a  relaying  Ku-band  satellite  and  the  air-to-ground 
transmission  date  rate  was  4.8  kbps  via  UHF  satellite.  The  Yurie  Systems’  LDR-50  ATM 
access  concentrator  was  used  for  ATM  WAN  switch  and  an  IBM  8260  multiprotocol  N- 
way  switch  was  used  for  the  ATM  LAN  switch.  The  ATM  network  interface  cards  were 
either  products  from  FORE  Systems  or  Sun  Microsystems.  The  end  stations  were  SUN 
Ultrasparc  Il-xi  workstations  miming  Solaris  2.5.1  and  Pentium  11-400  PCs  running  NT 
4.0.  The  on-board  LANs  were  155  Mbps  ATM  and  10/100  Mbps  Ethernet.  In  the 
EFX99  demonstration,  Boeing’s  airborne  electronically-steered  Phased- Array  Antenna 
(PAA)  transmit  unit  may  be  deployed  for  air-to-ground  transmission  as  well  as  the 
existing  capability  of  receiving  ground-to-air  wireless  ATM  traffic. 

ATM  Handover  Demonstration:  The  goal  of  the  ATM  handover  testbed  is  to  study  the 
impact  of  hand-over  on  multimedia  applications  while  the  mobile  platform  is  moving 
from  one  satellite  footprint  to  another.  The  demonstration  system  consists  of  two  satellite 
RF  links  from  an  airborne  mobile  platform  to  each  of  two  ground  stations.  The  two 
ground  switches  were  connected  by  an  ATM  link  at  25  Mbps.  The  two  satellite  links 
between  the  mobile  platform  on-board  switch  and  the  two  ground  switches  were 
simulated  by  two  T-1  links  at  different  RF  frequencies.  The  move  of  the  platform  from 
satellite  footprint- 1  to  satellite  footprint-2  was  simulated  by  manually  tuning  the  two  RF 
link  attenuators.  The  hand-over  process  and  the  delay  time  were  investigated  while 
running  a  variety  of  applications.  Three  types  of  applications  were  used  for  tests  and 
demonstrations:  FTP/MFTP  data/video  transfer,  remote  video-on-demand,  and  video 
teleconferencing.  The  actual  applications  are  PictureTel’s  Live  50,  Starburst’s  Multicast 
FTP  (MFTP)  with  a  user  client  interface,  Microsoft’s  Windows  Explorer,  Media  Player, 
NetMeeting  and  White-boarding.  The  end  stations  were  Win95  PCs  with  Pentium  166  or 
higher  processors.  Depending  on  the  tests,  each  PC  had  a  Real  Magic  MPEG-1  or 
MPEG-2  hardware  decoder  card.  The  ATM  switches  were  the  IBM  8285  workgroup 
switches  with  T-1  expansion  modules  and  Multiprotocol  S-witching  Services  (MSS) 
module  that  functions  as  an  ATM  LANE  server.  The  PC’s  network  interface  cards  were 
the  PCI  25  Mbps  ATM  from  IBM  or  FORE  Systems. 
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9.3.4.  Issues  and  Future  Works 

The  WATM  working  group  is  currently  focusing  on  two  major  tasks  that  include 
specifications  for  mobile  ATM  and  the  radio  access  layer.  The  specification  of  mobile 
ATM  deals  with  suitable  extensions  to  the  existing  specifications  for  location 
management,  handoff,  routing,  addressing,  and  traffic  management.  The  specification  of 
the  radio  access  layer  addresses  the  physical  layer,  medium  access  control,  data  link 
control,  and  radio  resource  control.  The  major  thrust  of  the  working  group  includes  the 
following  issues  of  addressing  architecture,  mobility,  location  management,  and  radio 
access. 

Architecture:  Two  approaches  are  under  consideration;  one  is  an  integrated  model,  which 
incorporates  all  mobility  and  radio  functions  into  the  ATM  switch,  and  another  is  an 
access  model,  which  offloads  some  functions  (e.g.,  radio  resource  control)  from  the 
switch  to  the  access  point.  The  first  approach  places  more  complexity  in  the  switch  while 
the  latter  approach  requires  a  new  access  point  control  protocol  to  convey  messages 
between  the  access  point  and  the  ATM  switch. 

Handoff  Signaling:  The  aim  of  handoff  signaling  is  to  enable  wireless  terminals  to  move 
seamlessly  between  access  points  while  maintaining  connections  with  their  negotiated 
Quality  of  Service  (QoS).  The  proposed  handoff  algorithm  under  consideration  by  the 
working  group  is  a  backward  handoff  through  the  old  access  point. 

Location  Management:  Two  schemes  are  under  consideration.  One  integrates  location 
management  with  ATM  signaling,  and  the  other  partitions  the  address  space,  keeping 
location  management  external  to  existing  signaling.  Existing  location  management 
solutions  (e.g.,  GSM,  IS-41  MAP,  mobile  IP)  are  also  being  investigated. 

Radio  Access:  The  Broadband  Radio  Access  Network  (BRAN)  project  by  the  European 
Telecommunications  St^dard  Institute  (ETSI)  is  currently  developing  broadband  radio 
local  loops  and  other  radio  access  systems  operating  at  data  rates  of  25-155  Mbps.  The 
WATM  and  BRAN  working  groups  are  jointly  developing  the  radio  access  layer 
specification. 

The  common  issues  in  wireless  ATM  and  mobile  networks  include,  but  are  not  limited  to, 
the  connection  and  location  management,  routing,  and  hand-over.  Although  the  broad 
issues  of  mobility  may  remain  the  same,  the  solution  for  the  wide-area  mobile  network 
segments  with  many  fixed  end-users  will  differ  from  that  of  the  mobile  terminals  in  a 
local-area  network  environment.  One  example  is  the  impact  of  mobile  ATM  technology 
on  satellite  and  ad  hoc  networking.  The  major  impact  of  these  technologies  on  ATM  is 
the  need  for  a  mobile  PNNI  link.  Relatively  little  work  has  been  done  in  this  area.  IBM 
is  currently  developing  jointly  with  Boeing  a  mobility  extension  to  the  PNNI  routing 
protocol  applicable  to  mobile  ATM  network  technology. 
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10.  SUMMARY  AND  CONCLUSIONS 


The  basic  objective  of  the  ATM  technology  investigations,  which  are  described  herein, 
was  to  develop  an  ATM  network  for  advanced  airborne  C4I  applications,  and  then 
demonstrate  that  network  in  as  realistic  and  stressing  an  environment  as  possible.  The 
most  realistic  airborne  C4I  environment  available,  short  of  a  very  expensive  airborne  test 
and  demonstration,  was  the  AWACS  Open  System  Architecture  (OSA)  prototype  system 
in  the  Boeing’s  Integrated  Technology  Development  Laboratory  (ITDL).  The  OSA 
system  was  being  developed  as  a  candidate  standard  for  the  mission  avionics  architecture 
for  future  advanced  C4I  platforms,  particularly  for  retrofits  to  existing  E-3s  and  for  an 
Advanced  AWACS.  The  scenario  selected  for  the  demonstration.  Joint  Suppression  of 
Enemy  Air  Defenses  (JSEAD),  had  already  been  established  and  was  well  rehearsed.  The 
demonstration  would  be  conducted  with  operators  in  the  loop;  the  ATM  network  would 
replace  the  OSA  baseline  backbone  network,  which  was  (at  the  time)  a  combination  of 
FDDI  and  Ethernet.  A  successful  live  demonstration  of  ATM  in  support  of  the  OSA 
system  in  a  stressful  airborne  C4I  scenario  would  then  help  lay  the  groundwork  for  the 
application  of  ATM  technology  in  near-term  and  evolving  airborne  C4I  programs,  such 
as  the  Advanced  AWACS. 

Interpretation  of  Data  and  Conclusions: 

Development  and  demonstration  were  completed  and  were  highly  successful,  and  further 
illustrated  that  the  basic  requirements  for  an  Advanced  AWACS  could  be  met  with 
networks  based  on  ATM  technology.  The  ATM  network  was  evaluated  and  tested 
extensively,  and  demonstrated  performance  fully  acceptable  for  an  advanced  C4I  aircraft. 
Performance  equivalent  to  the  combined  FDDI  and  Ethernet  was  demonstrated,  and  stress 
testing  of  the  network  indicated  that  significant  reserve  capability  was  available. 

Significant  technical  details,  particularly  on  interoperability  between  various  venders' 
products  and  multicast  design  options,  were  developed  during  the  course  of  the  design, 
implementation,  and  subsequent  testing.  This  information,  reported  herein,  is  available  as 
the  basis  for  future  efforts  and,  further,  has  been  of  great  value  in  related  efforts  such  as 
wireless  ATM  development  and  the  Air  Force’s  Expeditionary  Force  Experiment  (EFX) 
program  support. 

The  ATM  architecture  development,  while  not  without  a  few  problems,  was 
accomplished  on  schedule  and  without  great  difficulties.  A  great  deal  of  information 
about  ATM  technology  was  accumulated.  While  the  ATM  technology  is  maturing  at  a 
rapid  pace,  it  is  not  yet  as  mature  as  older  networking  technologies  with  which  it  is  often 
compared,  such  as  Ethernet.  We  had  a  few  problems,  as  noted  in  the  body  of  the  report, 
but,  as  with  any  technology  at  this  stage  in  the  development,  a  few  growing  pains  remain. 
While  ATM  is  a  very  complex  and  evolving  technology,  the  effort  here  establishes  that  it 
is  sufficiently  mature  at  this  time  to  be  highly  successful  in  airborne  applications.  The 
interoperability  and  standardization  issues  described  indicate  that  we  still  need  to  go 
through  the  system  integration  and  testing  process.  However,  the  ATM  networking 
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technology  is  sufficiently  mature  to  be  viable  for  airborne  C4I  applications  with  very 
little  risk. 

Future  C4I  Aircraft  Architectures: 

The  investigation  illustrated  the  versatility  and  robustness  of  ATM  to  an  extent 
unexpected  at  the  start  of  the  program.  It  was  assumed,  as  we  began,  that  the  OSA 
architecture  would  become  a  widely  used  standard,  and  that  this  architecture  would  be 
simply  repeated  in  the  various  airborne  C4I  programs  then  under  way  in  parallel.  Several 
programs  did,  in  fact,  select  ATM  as  an  onboard  network  during  the  course  of  this  effort, 
but,  interestingly  each  chose  (and  was  able)  to  optimize  its  particular  design  based  on 
their  own  detailed  requirements,  and  the  expected  OSA  standard  was,  in  fact,  not  adhered 
to.  Examples  include: 

•  Advanced  AWACS  OSA  Program:  ATM,  Ethernet  (Redundant) 

•  US  AWACS  Extend  Sentry  Step  1  Program:  Fibre  Channel 

•  NATO  AWACS  Midterm  Program:  Gigabit  Ethernet 

•  EFX98  Program:  ATM,  Ethernet  (Redundant) 

•  Wedgetail  Program:  Fast  Ethernet 

•  NIMROD  Program:  Fast  Ethernet  (Redundant) 

This  situation  further  reflects  the  very  rapid  pace  of  the  ATM  technology  developments, 
and  the  flexibility  and  breadth  of  the  products  now  available.  The  ability  to  develop  an 
architecture  simply  and  quickly  with  COTS  products  makes  a  standard  architecture 
unnecessary  and  possibly  even  cumbersome. 


The  program  reported  here  had  its  greatest  success  in  support  of  the  EFX  demonstrations. 
This  success  validated  the  efforts  reported  herein  as  being  a  significant  step  forward  in 
the  development  of  ATM  for  C4I  aircraft.  Originally,  ATM  was  viewed  by  the  EFX 
program  as  having  relatively  high  risk.  Further,  the  ATM  on-board  systems  planned  were 
supposed  to  be  only  a  back-up  to  Ethernet.  Through  our  demonstration,  ATM  was, 
instead,  accepted  by  the  program  as  the  primary  aircraft  on-board  LAN  for  the  mission 
avionics  systems.  We  were  also  able,  based  on  our  work,  to  demonstrated  that  ATM  was 
sufficiently  mature  to  be  accepted  onto  the  EFX  airborne  C4I  platforms  a  year  ahead  of 
the  original  schedule,  in  EFX98  rather  than  EFX99.  Also  interesting  was  the 
development  and  fielding  of  distinctive  and  different  network  architectures  for  the  three 
demonstration  platforms  equipped  with  ATM  for  EFX98.  These  were  the  TS-3,  E-3 
AWACS,  the  JFACC  (Joint  Forces  Air  Component  Commander)  aircraft,  and  the  EOC 
(Enroute  Operations  Center)  aircraft. 

Recommendations  for  Future  Efforts: 

Significant  advances  in  ATM  technology  development  for  airborne  C4I  applications  are 
being  achieved  and  transferred  at  a  rapid  pace,  particularly  in  the  commercial  technology 
arena.  However,  areas  where  future  efforts  could  make  significant  contributions  include. 
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a)  Development  of  small  ruggedized  ATM  switches,  specifically  for  aircraft 
applications. 

b)  Continued  evolution  of  the  commercial  ATM  standard  to  include  mobile 
networks. 

c)  Continued  wireless  ATM  technology  development. 

d)  Development  of  complex  networking  functionality  for  airborne  networks. 

e)  Further  development  of  multicast  applications. 

f)  Development  of  designs  and  applications  for  nonsymmetrical  networks. 

g)  Continued  development  and  commercialization  of  high-gain  phased  array 
antenna  technology. 

Also  in  the  planning  stages  are  significantly  more  complex  demonstrations  under  the 
auspices  of  the  EFX  program.  The  wide  area  ATM  effort  from  EFX98  will  be  expanded 
by  the  Air  Force  in  1999,  but  not  to  the  extent  we  had  originally  planned.  A  significant 
number  of  SATCOM  and  networking  issues  (which  are  not  trivial)  were  identified  in  the 
EFX98  design  studies  and  during  the  experiments.  The  EFX98  exercise  was  the  first 
time  multiple  aircraft  were  networked  together  (via  TCP/IP),  rather  than  simply  receiving 
broadcasting  in  an  ATM  format.  We  believe  that  attempts  were  made  to  work  the 
JFACC,  the  EOC,  the  TS-3  AW  ACS,  and  perhaps  a  JSTARS,  all  as  a  network.  We 
proposed  demonstrating  a  full-up  ATM  network  for  1999,  but  the  Air  Force  would  not 
accept  the  risk.  We  are  now  shooting  for  the  year  2000  exercise. 


The  wide  area  wireless  (SATCOM)  networking  technology  area  is,  therefore,  where 
significant  follow-on  effort  to  the  current  work  done  to  date  is  very  badly  needed.  We 
must  solve  the  wide  area  wireless  (SATCOM)  ATM/IP  networking  and  related  satellite 
communications  problems,  tind  further  demonstrate  to  the  Air  Force  that  we  can  build  a 
network  that  will  work  effectively.  The  necessary  ATM  test  and  evaluation  laboratory  is 
set  up  and  running,  thanks  to  Rome  Laboratory.  We  should,  in  a  follow-on  effort,  define, 
analyze,  design,  and  build  wide  area  network  components  and  related  software,  and  test 
and  demonstrate  them  in  the  laboratory  -  much  as  was  done  under  this  Rome  Laboratory 
contract.  This  follow-on  effort  would  then  transition  directly  into  the  EFX2000  for  flight 
testing  with  multiple  airborne  platforms. 
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APPENDIX  A:  Data  Exploitation,  Mission  Planning,  and  Communications  System 


The  data  exploitation,  mission  planning,  and  communications  (DEMPC)  system  (Figure 
A.l)  provides  collection,  processing,  storage,  display,  and  control  functions  in  support  of 
target  search  and  tracking  systems  such  as  SAR.  The  DEMPC  system  has  been 
developed  under  Government  contract  and  Boeing  IR&D  funding.  Boeing  is  a  first-tier 
subcontractor  to  provide  DEMPC  system  hardware  and  software  in  support  of  the  ground 
control  stations  (GCS)  of  the  Tactical  Endurance  -  Unmanned  Aerial  Vehicle  (TE-UAV) 
Advanced  Concept  Technology  Demonstration  (ACTD)  for  Tier-II  UAVs.  Specifically, 
the  DEMPC  system  provides  the  following  functions: 

a.  Mission  planning. 

b.  Mission  monitoring. 

c.  EO/IR  display. 

d.  SAR  sensor/SGP  status  display. 

e.  Map  display. 

f.  Aircraft  location  data  map  display. 

g.  Hardcopy  printout. 

h.  Airborne  VCR  and  SAR  sensor  payload  control. 

I.  Interface  to  external  JDISS  system. 

j.  Interface  to  external  Trojan  Spirit  System. 

k.  Conversion  of  RS-170  imagery  to  National  Imagery  Transmission  Format  (NITF). 

l.  Video  recording  in  National  Television  Standards  Committee  (NTSC)  format. 

m.  Payload  imagery  freeze  frame. 

n.  Digital  payload  data  storage. 

o.  Payload  data  annotation. 


IIS 


Video  Driver  i -  Video  Driver 


Figure  A.1:  DEMPC  System  Block  Diagram 
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Abstract 

We  demonstrated  an  integrated  battlespace  simulation  on  Advanced  AWACS  prototype 
network,  supporting  realistic  O'*!  applications  such  as  real  time  battle  management,  SAR 
image  processing  and  analysis,  and  air  tasking  order  monitoring.  In  this  paper,  we  will 
first  describe  an  integrated  battlespace  simulation  and  its  demonstration  scenario,  then  the 
ATM  testbed  for  integrated  battlespace  simulation  in  both  ATM  LAN  Emulation  and 
Classical  IP  over  ATM  multicast  configurations.  Finally,  we  will  describe  the  network 
performance  test  (with  netperf  and  nttcp  benchmark  tools)  and  the  application 
performance  test  (with  AWACS  mission  computer  program  and  display  console  program) 
of  FDDI,  ATM  LAN  Emulation,  and  Classical  IP  over  ATM  networks. 


Introduction 

The  CT  platform  (e.g.,  AWACS)  plays  a  major  role  in  battlespace  management.  A  future 
CT  platform  will  require  an  advanced  mission  avionics  architecture  to  meet  increased 
information  processing  requirements  of  future  missions.  The  implementation  of  such 
advanced  mission  avionics  and  the  simulation  of  advanced  C'*!  aircrafts  in  the  battlespace 
are  under  study  at  Boeing.  The  battle  management  systems  are  simulated  in  the  ATM 
network  environment  with  the  multiple  highend  workstations  representing  hardware-in- 
the-loop.  The  simulation  sequence  consists  of  video  images  from 
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the  sensor  image  simulation  laboratory  (UAV  Ground  Station)  to  the  battlespace 
management  station  (Advanced  AW  ACS)  where  it  is  processed  and  disseminated  to  the 
fighter  aircraft  displays  (Advanced  Fighter  Dome).  In  this  paper,  we  will  describe  an 
Integrated  Battlespace  Simulation  (IBS)  supporting  realistic  O'*!  applications;  real  time 
battle  management,  SAR  image  processing  and  analysis,  and  real  time  air  tasking  order 
(ATO)  monitoring.  Then,  we  will  describe  ATM  testbed  for  integrated  battlespace 
simulation  and  benchmark  performance  test  of  the  network  and  Advanced  AW  ACS 
application  programs. 


Integrated  Battlespace  Simulation 

Integrated  Battlespace  Simulation  [1]  includes  the  unmanned  aerial  vehicle  (UAV),  C"*! 
platform,  and  fighter  aircraft  as  core  battlefield  components.  The  entire  sequence  of 
battlespace  management  from  off-board  sensor,  via  C''l  platform,  to  fighter  aircraft  is 
simulated  with  multiple  SUN  Sparc,  DEC  Alpha,  and  SGI  Onyx  workstations,  all 
intercoimected  with  an  ATM  OC-3  network  (Figure  1).  The  raw  image  sensor  data  is 
taken  from  a  predetermined  fixed  location  of  the  Image  Generator  (simulated  airborne 
UAV).  This  video  frame  data  is  captured  by  an  SGI  Onyx  video  processor,  stored  into  a 
video  frame  buffer,  and  processed  into  a  realistic  synthetic  aperture  radar  (SAR)  image  at 
the  SUN  Sparc-20s  (simulated  UAV  Groimd  Stations).  Then,  the  video  frame  buffer  is 
transferred  to  multiple  DEC  Alpha-600s  (simulated  Advanced  AW  ACS  platforms)  and 
DEC  Alpha  500  for  Toshiba  large  flat  panel  display  screen.  The  video  frame  buffer  is 
also  transmitted  with  additional  commanding  information  to  the  SGI  Onyx-2  in  a  Fighter 
Dome  (simulated  Advanced  Fighter)  along  with  voice  communications  between  the 
AW  ACS  and  Fighter.  The  information  is  then  displayed  in  the  fighter’s  cockpit  for  use 
as  a  target  information. 


Figure  1 :  Integrated  Battlespace  Simulation 
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Demonstration  Scenario  of  Integrated  Battlespace  Simulation 

The  battlespace  simulation  demonstration  scenario  is  derived  from  the  Joint  Suppression 
of  Enemy  Air  Defense  (JSEAD)  program.  It  involves  a  conflict  between  two  regional 
powers  which  has  evolved  into  an  active  combat  situation.  The  allied  forces  are  deployed 
in  the  area  supporting  in  a  defensive  coalition.  The  demonstration  events  occur  during 
the  early  days  of  the  conflict,  and  depict  JSEAD  activities  leading  to  the  achievement  of 
air  supremacy.  Within  this  environment,  enemy  forces  can  generate  counter-air  actions 
(air-to-air,  surface-to-air)  and  also  capable  of  conducting  land,  air  and  naval  combat 
operations.  The  demonstration  scenario  covers  the  following  major  phases  of  activity  [1]: 

(1)  Allied  air  forces  are  conducting  coordinated  attacks  against  enemy  air  defense  assets 
and  associated  command  and  control  elements  as  the  preliminary  step  toward  achieving 
air  superiority  in  theater. 

(2)  AWACS  uses  the  off-board  resource  data  as  well  as  on-board  sensors  to  detect  and 
target  threat  emitters,  and  initiates  strike  operation  with  available  assets. 

(3)  Advanced  Fighters  engage  threat  emitter  sites. 

(4)  AWACS  coordinates  follow-on  activities  against  other  enemy  fighter  aircrafts. 

Prior  to  start  of  simulation,  some  Surface-to-Air  Missile  (SAM)  threats  have  been 
suppressed  during  an  initial  wave  of  JSEAD  strikes.  Defensive  fighters  have  been  pushed 
up  to  counter  any  enemy  retaliatory  strikes,  including  cruise  missile  strikes  launched  from 
ground,  surface  and  air  platforms.  At  the  time  of  simulation  start  (t=to),  AWACS  has 
been  on  station  for  several  hours.  AWACS  has  an  established  air  picture  that  shows  the 
fighters  (tracks  with  ID),  a  special  point  for  the  air  defense  unit,  a  KC-135  tanker  orbiting 
to  the  theater  (optional)  and  ingress  fighters  on  Air  Tasking  Order  (ATO)-directed 
JSEAD  missions.  The  major  events  that  occur  over  time  in  the  scenario  are  as  follows. 

Start  of  ScenariorThe  threat  SAM  sites  surviving  initial  JSEAD  strikes  continue  activity. 
Event  1:  Fighter  positioned  about  hundred  miles  from  targets. 

Event  2:SA-10  SAM  target  begins  operation  with  sporadic,  intermittent  emission  pattern. 
Event  3: AWACS  identifies  new  threat  emitter,  retasks  airborne  UAV,  and  plans  for 
strike. 

Event  4:  AWACS  identifies  threat  emitter  and  diverts  ATO-directed  fighter. 

Event  5:  AWACS  notifies  Joint  Force  Air  Component  Commander  (JFACC)  of  action 
and  monitors  strike. 

Event  6:  Ground  UAV  Controller  uplinks  SAR  image  of  enemy  SAM  site  to  AWACS. 
Event  7:  The  fighters  receive  divert  tasking  and  SAR  image  of  target  from  AWACS, 
conduct  strike,  and  commence  egress  from  enemy  airspace. 

End  of  Scenario:  AWACS  detects  enemy  fighters  reacting  to  strike. 

ATM  Battlespace  Simulation  Testbed 

The  core  battlespace  components  are  simulated  with  the  multiple,  disparate  platforms  on 
ATM  network  testbed  shown  in  Figure  2;  AWACS  for  DEC  Alpha-500/600  workstations 
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running  Unix  4.0  on  PCIbus,  UAV  for  SUN  Sparc-20  running  Solaris  2.4  on  Sbus,  and 
Fighter  for  SGI  Onyx-1  (Onyx-2)  running  Irix  5.3  (Irix  6.4)  on  VMEbus  (PCIbus). 
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Figure  2:  ATM  Network  Testbed  for  IBS 


The  €“1  platform  (e.g.,  AWACS)  requires  a  network  that  is  capable  of  simultaneous 
unicast  and  multicast  for  data  distribution.  The  TCP/IP  unicast  is  used  for  operator- 
related  activities  between  AWACS  Mission  Computer  and  Display  Consoles.  The 
UDP/IP  multicast  is  used  for  common  data  broadcasting  to  all  display  consoles  within  a 
multicast  group  on  a  periodic  basis.  Unlike  a  connectionless  legacy  LAN  technology,  the 
multicast  capability  is  not  easy  to  implement  in  a  connection-oriented  ATM  technology 
[2].  The  ATM  multicast  configuration  details  used  for  the  integrated  battlespace 
simulation  network  can  be  referred  to  Ref.  [1,3]. 


ATM  Multicast  Configuration 

There  are  potential  approaches  to  address  the  ATM  multicast  problem  in  the  legacy  LAN 
environment,  for  example,  multipoint-to-multipoint  VPC  (virtual  path  connections),  a 
multicast  server,  or  overlaid  point-to-multipoint  connections.  However,  the  multipoint-to- 
multipoint  VPC  requires  a  protocol  to  allocate  unique  VCI  values  to  all  nodes  in  the 
multicast  group  and  such  a  mechanism  does  not  currently  exist.  The  multicast  server 
requires  a  point-to-multipoint  connection  with  all  nodes  as  well  as  a  point-to-point 
unidirectional  connection  from  each  node  to  a  multicast  server.  The  overlaid  point-to- 
multipoint  connections  requires  each  node  to  maintain  the  total  number  of  all  connections 
within  each  group.  Thus,  there  is  no  ideal  solution  yet  for  ATM  multicast  [2].  The 
existing  “Classical  IP  over  ATM  (CIP)”  protocol  supports  neither  broadcast  nor  multicast, 
while  the  ATM  LAN  Emulation  (LANE)  protocol  supports  only  a  broadcast.  The  higher 
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layer  protocols  for  ATM  IP  multicasting  (e.g.,  MARS,  MPOA,  PIM)  are  under 
development  [4], 

ATM  Classical  IP-based  Multicast  Solution:  The  ATM  Classical  IP  (CIP)  protocol 
lacks  a  broadcast  (multicast)  mechanism.  We  resolved  this  broadcast  (multicast)  problem 
of  ATM  Classical  IP  with  a  simple  configuration  solution.  The  simple  solution  is  to  set 
up  point-to-multipoint  permanent  virtual  circuit  (PVC)  connections  (Multicast  PVC) 
fi'om  a  broadcast  server  to  all  clients.  Since  there  is  no  such  server  in  CIP,  we  create  a 
virtual  broadcasting  node  (that  corresponds  to  a  broadcast  service  access  point)  at  the 
switch.  The  procedure  to  configure  this  CIP  broadcast  (multicast)  mechanism  will  be 
described  in  detail  elsewhere  [3]. 

ATM  LAN  Emulation-based  Multicast  Solution:  ATM  LANE  can  support  multiple 
independent  emulated  LANs  (ELANs),  and  the  membership  in  any  of  the  ELANs  is 
independent  of  the  physical  location  of  the  end  system.  For  the  integrated  battlespace 
simulation,  four  different  ELANs  were  set  up  to  support  the  ATM  multicast  groups; 
ELAN-1  (AWACS  Display  Consoles  subnet),  ELAN-2  (Fighter  subnet),  ELAN-3  (UAV 
subnet),  and  ELAN-4  (Voice  over  ATM  subnet).  The  AWACS  Mission  Computer  must 
be  a  member  of  all  ELANs  so  that  it  can  selectively  broadcast  information  to  any  of  the 
AWACS,  Fighter,  or  UAV  group  as  different  multicast  groups.  It  should  be  noted  that  the 
CIP  (or  LANE)  intrasubnet  protocol  works  only  within  its  own  logical  IP  subnet  (or 
ELAN),  thus  a  separate  router  is  required  for  communications  between  different  logical 
subnets  (or  ELANs)  [5]. 

Network  Benchmark  Test 

The  netperf  and  nttcp  were  used  for  performance  benchmarking  test  of  ATM-based 
networks.  Netperf  [6]  allows  to  measure  various  aspects  of  network  performance, 
focusing  on  bulk  data  transfer  throughput  (bandwidth)  and  request-response  (latency) 
tests  for  TCP  and  UDP.  Nttcp  is  a  benchmark  tool  for  determining  TCP  and  UDP 
performance  between  two  systems.  Nttcp  times  the  transmission  and  reception  of  data 
between  two  systems  using  the  UDP  or  TCP  protocols  and  it  tests  the  bulk  transfers  with 
variations  of  number  of  buffers  and  sizes.  All  tests  were  performed  in  three  network 
configurations;  FDDI,  ATM  LANE,  and  ATM  Classical  IP.  The  most  common  test  is  to 
measure  bulk  data  transfer  performaince  (throughput)  in  either  a  TCP  stream  or  a 
unidirectional  UDP  stream.  Figure  3  shows  a  TCP_STREAM  throughput  test 
performance.  The  maximum  throughputs  in  the  TCP_STREAM  test  of  FDDI,  ATM 
LANE,  and  ATM  CIP  were  96  Mbps,  108  Mbps,  and  118  Mbps,  respectively,  over 
variable  message  size.  The  throughput  increased  with  the  receive  and  transmit  socket 
buffer  size  but  it  is  relatively  insensitive  to  the  message  size  when  it  is  bigger  than 
maximum  transmission  unit  (MTU). 
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Figure  3(a);  ATM  CIP  TCP  Throughput 


Figure  3(b):  ATM  LANE  TCP  Throughput 
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Figure  3(c):  FDDl  TCP  Throughput 


The  second  test  is  to  measure  a  transaction  rate  performance.  A  transaction  is  defined  as 
the  exchange  of  a  single  request  and  a  single  response  (RR).  The  round-trip  delay  can  be 


estimated  from  a  transaction  rate;  with  a  1  KByte  message,  0.63  ms  (FDDI),  0.58  ms 
(ATM  LANE),  and  0.60  ms  (ATM  CIP),  all  for  TCP  traffic.  Figure  4  shows  TCP_RR 
test  results. 


RR_Message  Size  (kB) 


Figure  4(a):  ATM  CIP  TCP  RR  Performance 
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Figure  4(b):  ATM  LANE  TCP  RR  Performance 
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Figure  4(c):  FDDI  TCP  RR  Performance 

The  UDP  stream  performance  test  is  similar  to  a  TCP  stream  test.  The  one  difference  is 
that  the  transmit  size  can  not  be  larger  than  the  smaller  of  the  local  and  remote  socket 
buffer  size.  A  UDP_STREAM  test  in  Figure  5  shows  that  FDDI  can  handle  better  than 
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ATM  irrespective  of  socket  buffer  size.  Even  with  the  transmit  size  constraint,  it  still  may 
need  to  control  the  interval  between  packets  to  keep  UDP_STREAM  from  miming  away 
with  all  the  resources  of  the  ATM  network.  Note  that  the  delay  between  sending  packets 
was  not  counted  in  this  UDP  throughput  test;  this  can  be  a  subject  for  further  study. 
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Figure  5(a):  ATM  CIP  UDP  Performance 


Figure  5(b):  ATM  LANE  UDP  Performance 


Figure  5(c):  FDDl  UDP  Performance 
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The  UDP  transaction  rate  performance  is  shown  in  Figure  6.  Similarly,  the  average 
round-trip  delay  can  be  estimated  from  a  transaction  rate;  0.61  ms  for  UDP  in  all  cases 
with  a  1  KByte  message. 


Figure  6(a):  ATM  CIP  UDP  Transaction 

'  yZ  IBkB  buffer 


Figure  6(b);  ATM  LANE  UDP  Transaction 


Figure  6(c):  FDDI  UDP  Transaction  Rate 

Besides  the  separate  TCP  and  UDP  unicast  tests,  since  a  real  AW  ACS  application 
requires  TCP  unicast  and/or  UDP  multicast,  it  is  interesting  to  test  the  performance  of  (a) 
TCP  or  UDP  multicast,  (b)  simultaneous  TCP  unicast  and  UDP  unicast,  and  (c) 
simultaneous  TCP  unicast  and  UDP  multicast.  However,  it  should  be  noted  that  the  UDP 
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multicast  and  the  simultaneous  TCP  and  UDP  multicast  tests  are  not  easily  implemented 
with  network  benchmark  tools  [7].  They  are  tested  only  by  running  actual  AWACS 
application  programs  as  described  in  the  next  section.  The  one  way  for  us  to  closely 
simulate  the  scenarios  above  is  running  multiple  copies  of  netperf  at  the  same  time. 
Figure  7  shows  an  example  of  TCP  multicast  test  by  sending  a  TCP  STREAM  test 
message  to  all  destinations  (a.k.a,  TCP-All)  at  the  same  time. 


Figure  7(a):  ATM  CIP  TCP-All  Performance 


Figure  7(b):  ATM  LANE  TCP-All  Performance 
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Figure  7(c):  FDDI  TCP-All  Performance 
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Figure  8  shows  a  test  example  of  the  FDDI  network  in  the  simultaneous  TCP  and  UDP 
stream.  The  test  script  with  multiple  copies  of  netperf  commands  allows  to  run  TCP  and 
UDP  streams  at  the  almost  same  time.  It  is  worth  while  to  mention  that  these  tests 
(Figures  7  and  8),  based  on  a  special  test  script  with  multiple  netperf  commands,  need 
more  study  for  the  validity. 
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Figure  8:  FDDI  Simultaneous  TCP  and  UDP  STREAM  Performance 


Application  Benchmark  Test 

The  application  performance  test  was  performed  with  the  Advanced  AW  ACS  mission 
computer  program  (MCP)  and  display  console  program  (DCP).  The  C**!  platform  system 
loading  can  be  a  large  number  of  simulated  targets,  sensor  returns  (Radar  or  IFF  returns), 
Euid  active  tracks.  The  maximum  number  of  3,000  tracks  and  simulated  targets  were 
generated  in  this  IBS  demonstration.  Sensor  returns  were  then  generated  internally  by  the 
AW  ACS  Mission  Computer.  Once  the  number  of  simulated  targets  have  been  generated, 
the  automatic  track  initiation  will  be  started  and  the  tracks  generated  off  the  simulated 
sensor  returns.  This  information  is  continuously  transmitted  to  the  AW  ACS  Display 
Consoles  to  observe  the  simultaneous  TCP  unicast  and  UDP  multicast  performance  of  the 
Advanced  AWACS  application  running  over  each  network. 

Table  1  shows  a  test  summary  of  Advanced  AWACS  application  with  a  3,000-track- 
simulation  that  requires  transmission  of  simultaneous  TCP  unicast  and  UDP  multicast 
over  the  network.  The  AWACS  application  program  was  modified  for  this  test,  so  that 
the  socket  buffer  size  could  be  changed  at  a  running  time.  Test  results  showed  that  all 
networks  had  various  problems  associated  with  a  mission  computer  program  and/or 
database  transmit  problems  below  a  buffer  size  of  32kB.  The  MCP  problems  include  the 
occasional  disconnect/reconnect,  shutdown,  or  radar  returns  disappear  of  simulated  target 
data.  The  database  transmit  problems  are  meant  by  that  various  databases  do  not  get 
transmited,  i.e.,  either  no  target,  point  objects,  or  no  tracks  get  updated.  Above  64kB,  the 
FDDI  and  ATM  CIP  showed  normal  operation,  while  ATM  LANE  also  showed  mostly 
normal  with  an  occasional  panic  problem;  the  display  consoles  running  AWACS 
programs  occasionally  enter  a  panic  mode  [8]  and  automatically  rebooted. 
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Socket 
Buffer  Size 

FDDI 

Multicast 

ATM  CIP 
Multicast 

ATM  LANE 
Multicast 

1-4  kB 

MCP  Down 

Database  Transmit 
Poblem 

MCP  Down 
Database  Transmit 
Poblem 

MCP  Down 
Database  Transmit 
Poblem 

8  -  32  kB 

Database  Transmit 
Poblem 

Database  Transmit 
Poblem 

Database  Transmit 
Poblem 

64  kB 

Normal 

Normal 

Normal,  but 

Panic  Poblem 

128  kB 

Normal 

Normal 

Normal,  but 

Panic  Poblem 

512  kB 

Normal 

Normal 

Normal,  but 

Panic  Poblem 

1500  kB 

Normal 

Normal 

Normal,  but 

Panic  Poblem 

Table  1 :  Simultaneous  TCP  Unicast  and  UDP  Multicast  AWACS 
Application  Performance  with  3,000  Tracks  Simulation. 


Summary 

We  demonstrated  an  integrated  battlespace  simulation  with  an  ATM  network  testbed.  The 
ATM  testbed  was  configured  for  multicast  using  ATM  Classical  IP  and  ATM  LAN 
Emulation.  Then,  the  network  and  application  performance  was  compared  among  three 
different  network  configurations  of  FDDI,  ATM  LAN  Emulation,  and  ATM  Classical  IP. 
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ABSTRACT 

An  integrated  battlespace  simulation,  consisting  of  an  off-board  sensor,  an  airborne  CT 
platform,  and  a  fighter  aircraft,  was  performed  over  an  ATM  OC-3  backbone  network 
interconnecting  multiple,  disparate  processing  platforms  (i.e.,  SUN  Sparc-20s,  DEC 
Alpha-500/600s,  and  SGI  Onyx- 1 /Onyx-2).  A  multicast  capability  is  required  to  run  a 
realistic  battlespace  simulation  program  over  ATM  network.  However,  it  is  not 
supported  by  the  existing  protocols  (e.g..  Classical  IP  over  ATM).  A  simple  solution  that 
addresses  the  ATM  Classical  IP  multicast  problem  is  described  in  this  paper.  The 
network  and  application  performance  of  ATM  Classical  IP  is  then  compared  \vith  that  of 
FDDI  and  LAN  emulation. 


1.  INTRODUCTION 

The  integrated  battlespace  sensor-to-shooter  sequence,  fi’om  an  off-board  sensor  (e.g., 
unmanned  air  vehicle  -  UAV),  via  an  airborne  O'*!  platform  (e.g.,  airborne  early  warning 
and  control  system  -  AW  ACS),  to  a  fighter  aircraft,  was  simulated  in  an  ATM 
environment  with  multiple  platforms,  all  intercoimected  with  an  ATM  OC-3  network. 
Raw  image  sensor  data  was  first  taken  from  a  predetermined  fixed  location  of  an  Image 
Generator,  processed  into  a  realistic  synthetic  aperture  radar  (SAR)  image  at  SGI  Indigo- 
2  (simulated  airborne  UAV),  and  analyzed  at  SUN  Sparc-20s  (UAV  ground  station).  The 
SAR  image  was  then  transferred  to  multiple  DEC  Alpha-600s  (C''l  platform)  for 
evaluation,  and  then  transmitted  to  SGI  Onyx-2  (F-15  fighter  dome)  with  the  additional 
information  provided  by  the  O'*!  platform.  The  SAR  image  and  the  O'*!  information  was 
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then  displayed  on  the  fighter’s  cockpit  for  use  as  a  target  information  [1,  2].  The 
integrated  battlespace  simulation  network  requires  both  point-to-point  (unicast)  and 
point-to-multipoint  (multicast)  capability  for  command,  control,  and  information 
dissemination.  Unicast,  based  on  the  TCP/IP  protocol,  is  used  for  operator-related 
activities  between  the  C'*!  mission  computer  and  display  consoles.  Multicast,  based  on  the 
UDP/IP  protocol,  is  used  for  common  data  broadcasting  to  all  display  consoles  within  a 
multicast  group  on  a  periodic  basis. 

II.  ATM  MULTICAST  CONFIGURATION 

A  multicast  capability  is  not  trivial  to  implement  in  the  connection-oriented  ATM 
networking  technology.  There  are  potential  approaches  to  address  the  ATM  multicast 
problem  in  the  legacy  LAN  environment;  multipoint-to-multipoint  virtual  path 
connections,  a  multicast  server,  or  overlaid  point-to-multipoint  connections.  An  ideal 
solution  is  not  yet  available  [3].  The  existing  ATM  LAN  Emulation  (LANE)  protocol 
supports  only  a  broadcast  and  the  classical  IP  over  ATM  (CIP)  protocol  does  not  support 
broadcast  nor  multicast.  The  higher  layer  protocols  for  ATM  IP  multicast  (e.g.,  MARS) 
are  under  development  [4].  We  implemented  a  simple  solution  to  the  multicast  problem 
of  ATM  Classical  IP  and  compared  its  network  and  application  performance  with  that  of 
FDDI  and  ATM  LANE.  The  integrated  battlespace  simulation  ATM  testbed  consists  of 
multiple  platforms;  AWACS  for  DEC  Alpha-500/600  workstations  running  Unix  4.0  on 
PCIbus,  UAV  for  SUN  Sparc-20  running  Solaris  2.4  on  Sbus,  and  Fighter  for  SGI  Onyx- 
1  (Onyx-2)  running  Irix  5.3  (Irix  6.4)  on  VMEbus  (PCIbus).  ATM  switches  used  for  the 
testbed  were  Cisco  Systems’  LS-IOIO  and  Catalyst  5000.  ATM  adapters  were  FORE 
Systems’  PCA200EUX  for  PCIbus,  SBA-200E  for  Sbus,  and  VME-200  for  VMEbus  [5]. 

ATM  LAN  Emulation-Based  Multicast:  ATM  LANE  can  support  multiple  independent 
emulated  LANs  (ELANs),  and  the  membership  in  any  of  the  ELANs  is  independent  of 
the  physical  location  of  the  end-user.  Four  different  ELANs  were  set  up  for  the 
simulation  to  support  the  ATM  multicast  groups;  ELAN-1  (AWACS  Display  Consoles), 
ELAN-2  (Fighter),  ELAN-3  (UAV)  and  ELAN-4  (Vioce  over  ATM).  The  AWACS 
mission  computer  that  plays  a  key  role  of  command,  control,  and  information 
dissemination  to  multiple  ELANs,  must  be  a  member  of  all  ELANs  so  that  it  can 
multicast  (i.e.,  selectively  broadcast)  information  to  any  of  the  AWACS,  Fighter,  and 
UAV  multicast  groups. 

ATM  Classical  IP-Based  Multicast:  The  ATM  Classical  IP  protocol  lacks  a  broadcast 
(multicast)  mechanism.  The  simple  solution  is  to  set  up  point-to-multipoint  permanent 
virtual  circuit  (PVC)  connections  (Multicast  PVC,  hereafter)  from  a  broadcast  server  to 
all  clients.  However,  there  is  no  such  a  server  in  the  current  CIP  protocol.  We  have  to 
create  a  virtual  broadcasting  node  (that  corresponds  to  a  broadcast  service  access  point) 
within  the  switch.  The  procedure  to  configure  a  CIP  multicast  is  described  in  details  as 
follows: 
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1.  Configure  an  ATM  interface  (qaaO)  for  a  standard  “Classical  IP  over  ATM”  with  an  appropriate 
ATMARP  server  address,  operating  over  switched  virtual  circuit  (SVC)  connections. 

2.  Create  a  point-to-multipoint  permanent  virtual  circuit  (PVC)  node  (Multicast  PVC)  within  an  ATM 
switch  using  unique  vpi/vci  number  for  each  multicast  group,  i.e.,  AWACS,  Fighter,  and  UAV 
multicast  groups.  This  Multicast  PVC  virtual  node  serves  as  a  broadcast  access  point. 

3.  Create  a  virtual  IP  address  for  the  Multicast  PVC  virtual  node.  Note  that  a  unique  IP  subnet  address 
should  be  assigned  to  each  multicast  group  when  multiple  multicast  group  subnets  are  required. 

4.  Configure  a  new  ATM  interface  (qaal)  for  a  CIP  Multicast  PVC  virtual  node  at  both  the  host  and  the 
client  workstations  with  a  proper  virtual  IP  address.  Repeat  the  process  for  the  multiple  subnets,  as 
required. 

•  ifconfig  qaal  <host  station  multicast  IP  address>  netmask  255.255.255.0  at  a  host  station 

•  ifconfig  qaal  <multicast_PVC  virtual  IP  address>  netmask  255.255.255.0  at  all  client  stations 

5.  Bind  IP  addresses  to  the  unique  vpi/vci  numbers  at  a  host  workstation  and  multiple  client  workstations, 
such  as 

•  atmarp  -c  <multicast_PVC  virtual  IP  address>  qaal  <vpi>  <vci>  <revalidate>  at  a  host 
station 

•  atmarp  -c  <host  station  multicast  IP  address>  qaal  <vpi>  <vci>  <revalidate>  at  all  client 
stations 

6.  Make  the  final  configuration  (e.g.,  atmarp)  persistent  across  reboots  by  writing  a  start-up  script  as 
necessary. 

7.  Run  a  standard  “Classical  IP  over  ATM“  on  top  of  “MulticastPVC”  virtual  node  connections. 

This  permits  the  simultaneous  transmission  of  point-to-point  TCP  unicast  traffic  over 
SVC,  and  point-to-multipoint  UDP  multicast  traffic  over  multicast_PVC.  Figure  1  shows 
the  ATM  CIP  multicast  configuration  that  allows  for  selectively  broadcasting  to  the 
battlespace  groups. 
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Figure  1:ATM  Classical  IP  Multicast  Configuration  using  Point-to-Multipoint  PVCs 


III.  NETWORK  AND  APPLICATION  PERFORMANCE  TEST 

The  ATM  LAN  emulation  was  configured  first  and  evaluated  as  a  baseline  reference 
point.  The  overall  performance  and  scalability  of  the  ATM  LANE  network  is  affected  by 
its  broadcast  and  unknown  server  (BUS).  A  multicast  throughput  required  for  advanced 
C^I  platform  (a  minimum  40  Mbps  multicasting  data  to  multiple  display  consoles)  also 
depends  on  the  LANE  BUS.  Then,  the  BUS  throughput  was  tested  by  measuring  a 
broadcast  forwarding  rate  over  the  ATM  ELAN  [6].  Figure  2  shows  the  BUS  throughput 
as  a  function  of  the  maximum  transmission  unit  (MTU).  For  the  worst-case  MTU  of  64 
Byte,  the  BUS  throughput  of  ~60  Mbps  (in  Figure  2)  is  considered  to  be  the  upper  limit. 


Figure  2:  ATM  LANE  BUS  Throughput 
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Network  Benchmark  Test:  The  network  benchmark  tool,  Netperf  [7],  was  used  for 
performance  test  and  comparison  among  three  network  configurations;  FDDI,  ATM 
LANE,  and  ATM  Classical  IP.  The  most  common  network  benchmark  test  is  to  measure 
bulk  data  transfer  performance  (throughput)  and  transaction  rate  (latency)  for  a 
bidirectional  TCP  stream  or  a  unidirectional  UDP  stream.  The  maximum  throughput  in 
TCP_STREAM  test  of  FDDI,  ATM  LANE,  and  ATM  CIP  was  96  Mbps,  108  Mbps,  and 
118  Mbps,  respectively,  over  a  variable  message  size.  The  TCP_STREAM  throughput 
(Figure  3)  increased  with  the  receive  and  transmit  socket  buffer  size,  but  it  was  relatively 
insensitive  to  the  message  size  when  the  message  size  was  bigger  than  the  maximum 
transmission  unit  (MTU). 
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Figure  3(a):  FDDI  TCP  Throughput 
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The  UDP_STREAM  test  showed  that  FDDI  could  handle  UDP  traffic  better  than  the 
ATM  LANE  or  Classical  IP,  irrespective  of  a  socket  buffer  size,  as  shown  in  Figure  4. 
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Figure  4(a):  FDDI  UDP  Throughput 


Figure  4(b):  ATM  LAN  Emulation  UDP  Throughput 
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Figure  4(c):  ATM  Classical  IP  UDP  Throughput 
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The  UDP_Request/Response  (RR)  transaction  rate  was  tested  (Figure  5).  A  transaction  is 
defined  as  the  exchange  of  a  single  request  and  a  single  response.  The  round-trip 
average  latency  can  be  inferred  from  the  transaction  rate;  with  a  1  KByte  message,  0.63 
ms  for  FDDI,  0.58  ms  for  ATM  LANE,  and  0.60  ms  for  ATM  CIP,  all  for  TCP;  and  0.61 
ms  in  all  cases  for  UDP.  Then,  the  round-trip  delay  gets  longer  as  the  message  size  gets 
larger.  The  detailed  tests  will  be  described  elsewhere  [1]. 
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Figure  5(c):  ATM  Classical  IP  UDP_RR  Transaction  Rate 


Application  Benchmark  Test:  The  application  test  was  performed  with  AW  ACS 
mission  computer  and  display  console  programs.  The  C'*!  platform  system  loading  can  be 
a  large  number  of  simulated  targets,  sensor  returns  (e.g.,  radar  or  IFF  returns),  and  active 
tracks.  The  maximum  number  of  3,000  tracks  and  simulated  targets  were  created  and  the 
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sensor  returns  were  then  generated  by  the  mission  computer.  While  the  information  was 
continuously  transmitted  to  the  display  consoles,  the  simultaneous  TCP  unicast  and  UDP 
multicast  performance  of  the  AWACS  application  was  monitored  over  the  variable  track 
and  socket  buffer  size.  Test  results  showed  that,  below  a  buffer  size  of  32kB,  all  networks 
had  various  problems  associated  with  a  mission  computer  program  and/or  database 
transmit  problems.  Above  64kB,  the  FDDI  and  ATM  CIP  showed  normal  operation, 
while  ATM  LANE  showed  mostly  normal  except  an  occasional  panic  problem;  the 
display  consoles  running  AWACS  programs  occasionally  enter  a  panic  mode  [8]  and 
automatically  rebooted. 


IV.  SUMMARY 

The  integrated  battlespace  simulation  (IBS)  was  performed  over  ATM  network.  ATM 
multicast  configuration  with  the  multiple  logical  subnets  of  Classical  IP  multicast-PVCs 
and  multiple  emulated  LANs,  supporting  the  IBS  network  testbed  with  multiple 
platforms,  was  described.  The  network  and  application  performance  was  then  compared 
among  three  configurations  of  FDDI,  ATM  LAN  emulation,  and  ATM  Classical  IP 
Multicast-PVC  networks. 
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